Building up a Dragon in ATX form

For the discussion of all hardware related topics.
Post Reply
Julian
Posts: 67
Joined: Mon Nov 21, 2011 1:06 pm

Building up a Dragon in ATX form

Post by Julian »

I've been assembling a Dragon in ATX format, using some custom expansion slots to fit cards for various functions. So far I have the CPU/SAM board fitted (and tested) and just built up a RAM/ROM board but in this form there is no real IO.

Just wondering if there is any tried and tested binary images for bringing up such hardware?

I have the PIA and VDG boards coming in the post but that is at least a week away and I'm impatient ;)

I can monitor about 100 channels with my logic analyser but the interface board needs some parts so I'm pretty much blind beyond monitoring the cartridge port using the LA built in to my oscilloscope
Julian
Posts: 67
Joined: Mon Nov 21, 2011 1:06 pm

Re: Building up a Dragon in ATX form

Post by Julian »

So here's my plan - write $AA to every byte in the lower 32K to initialise. Then loop through the same memory, read each byte and test for $AA then changing $AA to $55. Do the same again swapping the two values. Any errors (ie reading an unexpected value will result in the upper byte of the test address being written to either P0 for the first pass or P1 for the second pass. Rinse and repeat. The code for the first loop resides at $8000, the second loop resides at $A000. This forces the code to exercise all of the SAM encoded address blocks for R0, R1, P0, P1 and low ram.

I just need a LS138 on the S0..2 lines and a pair of latches to capture P0 and P1

The only thing missing is to provide an indicator as to progress but I can do that with a third latch attached to P2 if I want to do more than just monitor using my logic analyser

It just needs about 70 lines of assembly code (including the vector table)
Julian
Posts: 67
Joined: Mon Nov 21, 2011 1:06 pm

Re: Building up a Dragon in ATX form

Post by Julian »

The IO and VDG cards only made it as far as Hillingdon (Heathrow for those that don't know London) so no more build this weekend

The 40-pin connectors for the logic analyser board have turned up this morning though so I have a fighting chance of actually doing some real testing of the built-up components
Julian
Posts: 67
Joined: Mon Nov 21, 2011 1:06 pm

Re: Building up a Dragon in ATX form

Post by Julian »

All of that would be great if I'd order 32 pin connectors... too much on my mind - that's my excuse and I'm sticking to it
User avatar
robcfg
Posts: 1633
Joined: Sat Apr 04, 2009 10:16 pm
Location: Stockholm, Sweden
Contact:

Re: Building up a Dragon in ATX form

Post by robcfg »

Heh, I know the feeling too well...

Sometimes is not good to try and rush things ;)
Julian
Posts: 67
Joined: Mon Nov 21, 2011 1:06 pm

Re: Building up a Dragon in ATX form

Post by Julian »

Pretty much ready to spin this up for real - I have CPU, SAM, PIAs, RAM, ROM and VDG all hooked up. The LA board is a bunch of spaghetti and a tiny bit too wide to fit nicely... and certainly doesn't fit in the ATX case (again I didn't think this through and I need to make a different arrangement of the boards to fit nicely)

The Serial board is incomplete and unusable in this state so will be sitting out the initial spin-up
Julian
Posts: 67
Joined: Mon Nov 21, 2011 1:06 pm

Re: Building up a Dragon in ATX form

Post by Julian »

Update on progress - the ATX machine is running, I have everything except the cartridge port, real time clock and expanded audio built and working.
The keyboard interface is waiting on a single chip to arrive (basically an Arduino performing the translation of a PS2 keyboard's serial data into something usable)

I'm working on a revised video board that hugely simplifies things for PAL and NTSC (waiting on some bird seed SMD parts). This uses a very small CPLD to replace the mass of logic chips that pad NTSC video timing into PAL instead. The board also replaces the LM1889 video encoder, replacing it with the much more modern AD724 or AD725 encoder. These give superb, clean composite output but also generate separate luma and chroma signals for S-video and as a bonus the input to the AD chips is RGB so I've put together a circuit that translates the native YUV output of the 6847 into RGB (a similar trick is used on the SECAM version of the Dragon and if this version I've built doesn't work I will be adopting the SECAM circuit!)

The boards that run the CPU, SAM, RAM and ROM (currently two cards) are next in line so I can use one of Ciaran's SAMx8 plug-ins. The result is a single board instead of two and a much more capable build :)

I'm leaving the audio expansion card 'til last - the goal is one or two AY-3 sound generators. Bizarrely I've been sent a bunch of full AY-3-8910 chips (thank you Leslie) that means I can test the expansion itself and the emulated version of the AY-3-8913 chip I'm planning to use in separate steps

I say the audio card is last but this is also not quite the end of the story - the backplane for the ATX build has a huge area given over to plugging in a ready-to-roll FPGA board that provides an AMD Artix-7 chip (the same as used in the Spectrum Next phase 2) and a massive amount of memory. This isn't to replace the CPU (although it could), instead the goal is to replace the SAM/RAM/ROM sub-system so I can really go to town and create something comparable to the CoCo Deluxe or CoCo3. The FPGA also allows me to exploit the extra speed available through a HD63C09 without messing up the video output, effectively bumping the clock speed up to four times that of the original design while allowing the same hardware to run at the original clock speed if you want. The FPGA also unlocks the foundations for the plans I have on an expanded VDG setup. I had planned on doing this as a separate video board but I've since realised that having it inside the FPGA means I could potentially exploit the wider data bus between the FPGA and its RAM to simplify the video timing I had sketched out, or to double the video bandwidth again (my time slicing had the video at 1xClk or 2xClk irrespective of whether the CPU was 1x, 2x or 4x). In real terms that means even in the highest resolution I was planning for you would have 4 bits per pixel (from a 16 colour palette). Knocking the resolution down (2x1) either means 8 bits per pixel using a palette of 512 possible colours or direct 323RGB. Right now my head is still spinning with possibilities
Post Reply