archive.worldofdragon.org

Apologies for not posting anything about this here - although I'm pretty sure a fair percentage are already aware. I've been designing replacement and upgraded Dragon 32 boards for the last couple of years.

The original (in my terms rev2) board is in the wild and (so far) is working without too much trouble, although I've made a few refinements in the last year.

The enhanced (rev3) board (basically a 256K board with Stewart Orchard's RAM banking built in) mostly works although it seems to have reliability problems with the PIAs (most obviously with the video control) with floating signals for CSS, A/G, GM, etc. but only on some boards.

The most recent board (rev4) is a step change, thanks to Ciaran's SAMx VHDL work, the rev 4 is a bit of a monster with a substantial list of improvements and enhancements. The stand-out points being much more RAM, fine grained banking and (if my calculations are correct) a much faster clock speed without breaking everything else. The board is in two flavours - a regular Dragon form factor and a Flex-ATX sized board with built-in MPI and a set of versatile expansion slots that use the ISA slot positions.

While I'd like to jump in with both feet and just build the ATX board and get on with the fancy stuff, I really need to test and verify the changes in smaller steps so the Dragon form factor is the next stop and I need to put out a call for help. While I can progress this singlehanded, it would be really helpful to obtain some assistance to check the design, build and operation. I need volunteers to check the board design before I fabricate it (hopefully to avoid wasting time and money on failed fabrication), to build the board and make sure it is actually possible to assemble (I build up every iteration for testing but I'm used to it and I need feedback on just how hard - or easy, it is). Finally I need volunteers to actually test the board, and the verilog code that operates my interpretation of the SAMx.

All of these projects are open source - anyone can have a play but I'm looking for a more concerted approach to finishing the design and pave the way to the ATX board...

Incidentally I have the MPI capability as a separate board that should allow the ports on the ATX board to be tested before full integration, this should also work with any other Dragon (it's just a regular MPI cartridge but with the 12V pins made safe)

Just to flesh things out a bit, and just in case you're curious as to what is available/done/being developed, here are some links to the projects:

The full-fat kitchen sink flex-ATX board that I'm working towards: https://github.com/jimbro1000/DragonRevX4KSEdition
The goal was to make something that fits in a regular mini-ATX case, uses the PC power supply, expansion ports, etc. The MPI ports would need a hole added to the case but I figure cutting a hold in a cheap PC case is significantly easier and cheaper than having a custom case made

The Dragon format board with most of the same features (no expansion slots or MPI): https://github.com/jimbro1000/Dragon32Rev3Proto
While this was going to be the end-goal of my work, it has become an intermediate step towards making the ATX board a reality. This is the one I need help with on testing. I have a lead on getting the board assembled so the hurdles to actually getting up and running should be reduced but it also means that the cost is that much higher as its no longer just the PCB. Some assembly may be required still but it would all be through-hole and some of it can be deferred

The upgraded (standard) board: https://github.com/jimbro1000/Dragon32Rev3
This is just a regular 64k or 256k upgraded Dragon 32 board with an added twist of moving the video circuit to a mezzanine board that allows you to choose between different video formats or options - the same approach is used on the newer Dragon format board.

My reproduction of the Dragon 32: https://github.com/jimbro1000/Dragon32Issue2
This really is just a Dragon 32 with a few lifestyle improvements - the upgrade path from 32k to 64k is much easier and doesn't need cut traces or bodge wires. The parallel port can be more easily adapted to the bit-banged serial port from a CoCo. Joystick ports are wired for two buttons each. (I have one board left for sale out of the last batch...)

PAL video board for rev3/4: https://github.com/jimbro1000/DragonPal
NTSC video board for rev3/4: https://github.com/jimbro1000/DragonNTSC
RGB/YUV/Composite video board for rev3/4: https://github.com/jimbro1000/DragonPalAD724
Synthetic 6847 replacement board (very much a prototype): https://github.com/jimbro1000/fpga6847rgb

Reproduction keyboard (cherry MX): https://github.com/jimbro1000/Dragon3264Keyboard
This includes support to work as a USB keyboard for emulation (not really suitable for a daily driver due to missing keys)

Hello Julian
It is by now more clear for me with those explainations.

As you know, I was very happy last year to use your issue 2 board.
I have created a minimalist Dragon 64 K Ram by populating the card with the minimum of componants.
I use it with a serial access to DriveWire for FLEX (with PIA outputs and DWRead and DWWrite subs).
For the video, I have connected HS to NHS and Clk to Vclk, so I have a simple Y luminance signal at 60 Hz without added lines.
On a LCD TV, I get a perfect black and white picture, or a colored picture with my RGBtoHDMI board.
Only 5V is necessary.
I noticed that a HD 63C09 IC is very less hot.

Looking further, the REV3 seems interesting to me with the 256K ram extension.
I'm waiting for brave testers before me ...

Thanks for the vote of confidence - and for reminding me that on the issue 2 board I'd added two solder-bridge jumpers to allow the PAL circuitry to be cut-out and run the board as NTSC.

One of my board-folk colleagues created a shim for the VDG to add-in the missing modulator circuitry if you want to run NTSC over composite. It's a little bit crude but it works. I've elaborated on that to create a better result for the NTSC video board for the rev3/4

The RevX4 boards (previously the Rev3proto) have arrived and I'm gearing up for build and test

https://github.com/jimbro1000/Dragon32R ... 32plus.png

This really is experimental and exists primarily to prove the customisation of the SamX code.

In its current form the board fits as standard in a regular Dragon case but adds the hardware serial port (as opposed to big-banged serial through the parallel port), this requires the Dragon 64 style case (late D32 or D64).

The video circuit is offloaded onto a daughter board, for testing purposes this will be the simple NTSC version.

The two PIA chips are replaced with WD65C21s, these can operate against a much faster clock speed (up to 10MHz) but are just as happy at 0.89MHz.
RAM is a single (massive) 4MB SRAM that should allow everything to run at up to 3.6MHz. The clock speed is 3 options now - 0.89MHz, 1.8MHz and 3.6MHz (if you have a 63C09 CPU). The video clock cycle is decoupled from the CPU so there should never be any loss of output. The only time the CPU can't run at this speed is while accessing the cartridge port ROM. This shouldn't be a problem however as the onboard ROM is 512K and can be mapped in 8K blocks into the 64k ram space. If the testing works out the ROM can be reprogrammed in system.

The SamX is intended to provide support for all the above and flexible RAM management (again in 8K blocks) with process separation and protection. As a slight twist the same chip can also provide limited blitter capability to copy blocks of RAM between pages (and between RAM and ROM). While blit operations could take place at any time, the intended usage is to exploit the vertical sync to copy blocks of 256 bytes (or more). The copy operation would be one byte per CPU clock cycle at the full 3.56MHz (irrespective of CPU speed). For comparison that would be nearly 256 bytes per horizontal line of video. A slower blit operation should be possible at nearly 128 bytes in the same time - that is nearly enough to copy the entire 64k address space in a single video frame. Such operations shouldn't be necessary with the RAM paging however as the entire address space can be swapped out in a single cycle.

The final part of the equation is support for twin AY sound generators (6 channels total). To provide support for all the extra devices the PIA mapped memory has been "disambiguated" to turn the lower (P0) block into 8 (4 addresses each). The PIA resides in the first block, the second is reserved for interacting with the video board (another future project). Blocks 3 and 4 are assigned to the sound generators.