Currently we build for a Dragon64 but are not doing anything but initial
boot testing work
-Memory usage:
+Dragon & COCO Memory Mapping Notes:
-The Dragon 64 has 2x32K banks of RAM which isn't sufficient but also 16K
-of cartridge space that can appear at 0xC000->0xF??? and two ROMs
+These platforms are built around the 6883 SAM multiplexor for the 6809
+processor. The SAM setup used in both cases allows for two different
+mapping modes selected by $FFDE/$FFDF (Map)
+Mode 0:
+ 0-$7FFF RAM
+ $8000-$FEFF ROMs (system and cartridges)
+ $FF00-$FFEF I/O
+ $FFF0-$FFFF Magically mapped from top of ROM
+
+Mode 1:
+ 0-$FEFF RAM
+ $FF00-$FFEF I/O
+ $FFF0-$FFFF Magically mapped from top of ROM
+
+Less well known is that in Mode 0 you can select which 32K bank you want
+mapped using $FFD4/5 (P bit)
+
+
+There are three other things to note
+
+1. The C000-FEFF range is the cartridge slot on the Dragon/COCO however it
+may (shades of MSX) contain an MPI (the multi cartridge expander board) in
+which case what is mapped depends upon $FF7F which is set by slot 1-4
+(actually 0-3) as (slot << 4) | slot (0x00 0x11 0x22 0x33...). Third party
+extenders go to 8 slots. Disk is always in slot 4. Right now we don't care
+about this but someone might if their disk is in another slot
+
+2. There are a variety of 'fat COCO' type boards up to 512K using a second
+SAM and reading not writing the SAM addresses
+
+These allow all the 32K pages to be mapped in the low 32K with ROM, and
+allows the low pages to be mapped low, in combination with high ram pages
+mapped high. ie you've got n pages, only n/2 of them are mappable up top.
+
+3. There is the 'Dragonplus' and the like for the Dragon32/64
+
+The DragonPlus provides a selection between three different low banks in
+the low 32K, and they can be overlaid with a 2K video RAM. In 32K Dragons
+abusing the video ram is the only way for a non cartridge app to move stuff
+initially between banks to set up the box (ewww...)
+
+Selection is done via $FFE2 bits 0/1 00 - normal RAM, 10 bank A, 11 bank B,
+1xx turns on the 2K video RAM overlay
+
+All this makes things a bit ugly as we want to run partially from Cartridge
+(banked or otherwise) and that means we must have ROM mapped high, and RAM
+low (there is no access to the high RAM with the cartridge paged in).
+
+Equally we want user space to run from low addresses (for commonality) and
+we want to protect kernel data from user accidents.
+
+The map we use is thus
+
+Kernel
+ 0xC000-0xFEFF Cartridge OS image
+ 0x0000-0x7FFF RAM1
+
+User
+ 0xC000-0xFEFF Cartridge OS image
+ 0x0000-0x7FFF RAM0 (or any other bank)
+
+this allows us to use all the banks effectively for 32K apps on all the
+combinations. It also allows us to use some banks in the fat COCO2 case to
+allow ~64K userspace apps
+
+The downside is that the interrupt handling and syscall entry are
+interesting as we have no common RAM to use for the stack as we switch
+around.
+
+As a result we are going to need to make stuff like syscall
+
+ map kernel RAM high
+ set kernel stack in highspace
+ enter syscall path
+ save registers and stuff
+ copy arguments into udata
+ jump back into a RAM 0 address
+ remap the catridge slot
+ jump into a cartridge helper
+ cartridge helper maps kernel pages low
+ shift S by $8000 bytes
+ do the actual syscall
+ in cartridge code switch the low memory back to RAM 0 (user)
+ jump into ram0
+ switch the kernel RAM high
+ shift S by $8000 bytes
+ restore everything
+ switch the ROM back in
+ return to user
+
+Thankfully the IRQ path can be a lot cleaner as we have nothing to save
+but the entry/exit registers
+
+The video is fortunately simpler as the top bit for the CPU accesses via
+the SAM uses the P bit as A15. The video takes B15 from the SAM not via P
+(unclear how this works on DragonPlus and this is complicated on the 'fat'
+ COCO add-ons as the video can be moved into high space too)
+
+This basic setup should be compatible with any 6883/74LS783 based system
+with 64K of RAM and at least 16K of ROM we can hide in. Note that the SAM
+decoder doesn't require the other 32K of ROM decodes is ROM, it can be RAM.
+However the COCO and Dragon don't allow for them being RAM.
+
+In theory Dragon32 + DragonPlus would also work but the lack of common RAM
+might make the the bank switch syscall path truely epic
+
+Disks
+
+Not supported yet.
+
+With an expander we should look across all the cartridges to find out which
+one is us and which one (should be slot #4) contains a cartridge with DK at
+0xC000 indicating its the disk cartridge. (Could in theory be several)
+
+Xroar emulates: DragonDOS, Delta and RSDOS disks. It doesn't emulate an
+extender currently but you can have a disk, becker port and "wrong" ROMs in
+one slot!
+
+Also to consider
+
+DriveWire - over Beckerport - serial 'virtual disk' protocol
+
+CoCoSDC: SDC virtual disk including LBA mode interface for SD hard disk and
+also flash for catridge slots (banked). Looks ideal but not documented
+usefully.
+
+Dragon WD2797
+ 0xFF40 command
+ 0xFF41 track
+ 0xFF42 sector
+ 0xFF43 data
+ 0xFF48 drive control latch
+
+Delta: WD2791
+
+RSDOS: WD1793
+
+Becker port at 0xFF40 (FF46 ? on Dragon)
+
+IDE: FF70-FF78 - data latched (write high/load, read low/high) [0-7 IDE regs
+ 8 maps the latches]
-This is a very experimental build to see what might be possible if we either
-replaced the ROM images or used a cartridge or both.