archive.worldofdragon.org

Yes, I saw the scans, but some connections are hidden by the NAND (Pin 11, Pin 1, the two inputs 4 and 12 seem to be connected, but I cannot see, what's fed in). I own no cartridge, so I can't simply make some measurements. But as Rink pointed out, there is no need anymore to take small EEPROMS and choosing a single, bigger one would simplify the circuit.

I'm new to that machine, and really don't know the games and programs available, but the 16k limit for cartridge space is a problem of course. That's probably hardcoded by the circuit and can't programmatically be changed by some kind of loader? Hm, and D32 games usually don't fit into 16k? So, only the more simple games could be relocated. Probably it's too big an effort and not worth doing it. I don't know...
So maybe the youtube-video "Dragon 64 connected to a HxC 2001 Floppy Emulator" (http://www.youtube.com/watch?v=pB__S8HuzOA) shows us a better solution, but where do you get a floppy controller cartridge from? Those seem to be rare. That's more or less the idea of Rink with a cartridge based loader that loads from cartridge memory instead of cassette tape.

Thank you everybody for your help. I got to do some research and reading first and don't wan't to waste your time with maybe no so good ideas .

Rolo wrote: So maybe the youtube-video "Dragon 64 connected to a HxC 2001 Floppy Emulator" (http://www.youtube.com/watch?v=pB__S8HuzOA) shows us a better solution, but where do you get a floppy controller cartridge from? Those seem to be rare.

A quick search of the forums: You can buy a new controller from LAFUMAT. Dantyr recently bought three of them.

Anyway, it would be interesting to see how much memory we can get into a single cartridge without skyrocketing the price.

Nice project indeed

Rolo wrote:Yes, I saw the scans, but some connections are hidden by the NAND (Pin 11, Pin 1, the two inputs 4 and 12 seem to be connected, but I cannot see, what's fed in). I own no cartridge, so I can't simply make some measurements.

If you want, I'll put a meter on the Dragon Chess board tonight and see what those connections are.

I'm new to that machine, and really don't know the games and programs available, but the 16k limit for cartridge space is a problem of course. That's probably hardcoded by the circuit and can't programmatically be changed by some kind of loader?

This would get complicated, and I can't say it'd work, but it might be possible for a "smart cart" to steal the 16K BASIC ROM memory space after running a menu. The cartridge connector includes a "Device Select Disable" pin which when low, disables the Dragon's on-board selection which would allow your cart across the 0x8000 - 0xFEFF range (32K - lower than that and you hit graphics memory). It's one thing I've never tried so I don't know if this pin will actually disable the ROM but I'd guess it would.

However, I think you'd run into compatibility issues. Any game that used routines from the BASIC ROM would fail. And you'd have issues with game variables since the programs think they're loaded into RAM and so freely change their values, but if you're running from a cart, you'd probably be running from a ROM.

I've also been wondering lately whether you can halt the CPU and then have a CPLD/FPGA/PIC whatever take control of the address and data lines etc. to access the Dragon's internal memory; and then wake the CPU up with an interrupt when finished. Just idle thoughts right now, I've not gotten as far as getting any idea of whether it would work.

Rink wrote:If you want, I'll put a meter on the Dragon Chess board tonight and see what those connections are.

Yeah, maybe this would be a good idea. This is the Dragon archive, so it does make sense to store all the information one can get about computer and peripherals. The description of the cartridges is not complete yet. So, if you don't mind, please do tell us.

I think, I'm going to buy one of LAFUMAT's disk controllers too and probably try the floppy emulator. That sounds like a good solution, for the tape and floppy programs or am I missing something?

Probably the best way would be, to split the cartridge problem into two parts:
1. a simple EEPROM based multi-cart for the cartridge games, which seem to be not so many. In the archive I can just see a few(?). Or does that list just show a small fraction of the cartridge titles, that were produced?
2. a device that loads the non-cartridge-programs into RAM, so that there is no need to relocate the code and to avoid the write-variables-into-ROM-problem. A little PIC that takes control of the system's buses and that is attached to a "big" memory on the other side. It could fill the RAM as fast as possible, without the Dragon doing anything itself. Maybe a few buttons and a small display for selecting the programs. Yes Rink, that would be nice. But a lot of work! Time consuming . And not very retro, since the PIC would be, by far, more powerful than the poor little Dragon.
By the way, does anybody know a good hardware description for the Dragon (except "Inside the Dragon") or does everybody just study the schematics. And how about a documented ROM-Listing (like there is for C64 or Apple II?

Rolo wrote:By the way, does anybody know a good hardware description for the Dragon (except "Inside the Dragon") or does everybody just study the schematics. And how about a documented ROM-Listing (like there is for C64 or Apple II?

You may want to look around both http://www.onastick.clara.co.uk/dragon.html and http://dragon32.info/ to see if they have any of the information you are looking for.

Rolo wrote:2. a device that loads the non-cartridge-programs into RAM, so that there is no need to relocate the code and to avoid the write-variables-into-ROM-problem. A little PIC that takes control of the system's buses and that is attached to a "big" memory on the other side. It could fill the RAM as fast as possible, without the Dragon doing anything itself. Maybe a few buttons and a small display for selecting the programs.

Just thought I'd mention that even if you do the loading in software, it only takes around 1 second to copy 32K from cartridge memory to main memory, so there's not much to gain from going for a faster hardware solution. My 256K RAM cartridge project used the software approach.

Rolo wrote: Yeah, maybe this would be a good idea. This is the Dragon archive, so it does make sense to store all the information one can get about computer and peripherals. The description of the cartridges is not complete yet. So, if you don't mind, please do tell us.

Got tied up but I'll definitely get something worked out this weekend.

Sorry about the delay guys; my PC's power supply has gone pop and I can't get at any of the software I use for electronics and schematics etc.

If no one has drawn something by the time I get a replacement, i'll happily do the job.

Sorry for the delay in posting this - but it's taken me until now to get a PC up and running again; and double-apologies if my own way of doing schematics seems a little odd (I was never taught to do it properly).

Here is a schematic for a Dragon Chess 8KB cartridge.



The two Texas Instruments eproms require a low on PD/!PGM for a read cycle. A high enables a Power Down mode which cuts power dissipation by over 70% apparently.

Odd wiring of the chip select logic - I can post a truth table if you like but basically, selection is controlled by !CTS (which is low when the Dragon wants to access cartridge memory space) and A12 to select which of the two 4KB eproms to use.