Hi Dave, Mike, et al.
MK14HAK wrote: ↑Sat Aug 05, 2017 3:11 am
Is it likely the design can be C4 /C1 compatible for keyboard and C1 graphics (32char line increment). Perhaps ACIA at $F000 for both. With selection by switch. Two version of Cegmon and the required kybd and video logic. ???
Very easily done. Plenty of room left in the FPGA on the DE0_CV board for lots of things. Current design uses only 6% of the available logic.
There are already switches for Speed, Hires On/Off. Could easily add switches for Machine config, BASIC ROM on/off, and also a selection of monitor ROMS.
MK14HAK wrote: ↑Sat Aug 05, 2017 3:11 am
I have no experience with FPGA design but what you have achieved so quickly seems amazing. (Where have you been hiding?)
That's the great thing about FPGA's, you can get things up and running really, really quickly.
I've been working with computer hardware since the mid 70's, but only got turned on to FPGA's around 2008. They've improved markedly in the last 5 years or so.
Have done a bit of work porting Gary's Coco3fpga project to a few different dev boards too.
MK14HAK wrote: ↑Sat Aug 05, 2017 3:11 am
I have my own ROM boot project lurching along down here and have been investigating SD card usage as a direct memory device rather than a FAT file system so I will be interested to see how your project develops from here.
By the way. I see Gary in his Yahoo group posts mentions he has Drivewire4 Apple2 client. Anyone know how to get hold of this ? I kinda like that serial option with an OSI client someday.
But option 5 for me.
Mike
PS Is there room for a real time clock. ...An updated OS with longer file names and date stamp. (move the overlays off track 6)
I like the sound of Option# 5 too, but it also requires the most work. (Doesn't everything that is worthwhile having?!

)
Just thinking aloud here....
Hooking an SD card into the design is fairly easy.
Grant Searle has a simple SPI SD card module in his "Multicomp" system.
More recently, Neal Crook has extended the module to accept both SD and SDHC cards:
https://github.com/nealcrook/multicomp6 ... roller.vhd
Requires 5 bytes of the memory map to address it.
I would be inclined to put it at somewhere like $C020?
It's a simple block type device, FAT file system would be a big overhead.
It would be theoretically possible to put that SD module onto a small FPGA board to hook it into a real OSI system too.
Wouldn't be too difficult to write a program to extract the blocks back into disk images on the PC side.
On the OSI side, this
immediately breaks compatibility with OS65D. New drivers would have to be written to drive the SD card.
However, OSI's rather unique disk layout doesn't easily map to a Block, or Track/Sector based system (SD card). At least I can't think of an easy way to do it?
HEXDOS, with its' 2048 bytes per track (or 4 x 512byte SD card blocks), may be a bit simpler to modify?
---
Haven't seen Drivewire for the Apple, but porting that to OSI you are still going to be stuck with the odd OSI disk format.
If the DW server side could be modified to read/write a whole track at a time it might be viable?
Updating a sector within tracks containing multiple sectors would still be
rather tricky.
Every attempt to write to a track would have to read that whole track down the drivewire link first, since you wouldn't know ahead of time whether a whole track was being written, or only a sector update.
The source code to the server side is available.Java isn't it?
I had a quick look at Gary's applefpga group. He hasn't released the source, but there is a 2KB rom image to mimic an Apple Super Serial Card (6551 ACIA) when talking to the drivewire server:
http://groups.yahoo.com/group/applefpga ... DW_256.obj
Probably do-able on the OSI....
---
A battery backed RTC would be pretty easy to add to either a real or fpga machine. Not really a fan of the *IRQ style real-time clock that HEXDOS uses though..
Cheers,
Leslie