FPGA Implementations

MK14HAK
Posts: 285
Joined: Wed Mar 16, 2011 1:49 am
Location: New Zealand

Re: FPGA Implementations

Post by MK14HAK » Sat Aug 05, 2017 3:11 am

RedskullDC wrote:
Thu Aug 03, 2017 2:14 pm

Is anyone else (apart from Jim) keen to actually take the plunge and use this project?
Yes, I think a few of us have been waiting for this to come the OSI platform and would be keen users.

I like Dave's option 5 for sure. SD card is way friendlier and the multiple configurations this offers would be well worth the extra work in the end.
Great work Leslie. I have no experience with FPGA design but what you have achieved so quickly seems amazing. (Where have you been hiding?)

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. ???

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)
600RevB:16K,2MHz,64x32,470,CEGMON
SuperKit:502,540B,542B,CEGMON, 8" and 5" FDDs
Cards:PE IO,6522 D-A-D, AY3-8910,ProgramGraphics,Color,UK101
WIP:Archive/Restore Util,HexDOS,FDD Emulator

RedskullDC
Posts: 41
Joined: Thu Jul 18, 2013 11:24 am

Re: FPGA Implementations

Post by RedskullDC » Sat Aug 05, 2017 8:45 am

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
Superboard II - RevD, 8Kb, DABUG monitor ROM.
FPGA C1P/C2/C4. 1-8MHz, 48Kb ram, CEGMON, 16KB Hires.

dave
Site Admin
Posts: 479
Joined: Tue Sep 09, 2008 5:24 am

Re: FPGA Implementations

Post by dave » Sat Aug 05, 2017 4:39 pm

It would not be hard to implement SD or CF interfaces on the OSI, but as you said, it would require software patches. I think that Lee Davison had done this for IDE / CF on other 6502 systems, and had looked into OS65D patches.

However, there are SD card libraries for PIC, AVR, ARM, etc. My thought is to put a small core on the FPGA to interface to the OSI disk interface board, and map the OSI track commands and data stream to an image file (WinOSI format is just a raw mapping of tracks to file position). That way the OSI does not need to be aware that it is not accessing a real disk. The key to compatibility would be mapping time delays to emulated spinning disk head position on a track buffer. When a STEP is issued or head is unloaded, the current track buffer could be written to the file. The current track position would dictate the file offset.

MK14HAK
Posts: 285
Joined: Wed Mar 16, 2011 1:49 am
Location: New Zealand

Re: FPGA Implementations

Post by MK14HAK » Sat Aug 05, 2017 9:04 pm

dave wrote:
Sat Aug 05, 2017 4:39 pm

a small core on the FPGA to interface to the OSI disk interface board, and map the OSI track commands and data stream to an image file (WinOSI format is just a raw mapping of tracks to file position). That way the OSI does not need to be aware that it is not accessing a real disk. The key to compatibility would be mapping time delays to emulated spinning disk head position on a track buffer. When a STEP is issued or head is unloaded, the current track buffer could be written to the file. The current track position would dictate the file offset.
This is onlong the lines of my FPGA (From Parts Gained Anywhere ;) ) project that has been ongoing for some time. Im using a C64 !! to stream a ROM image through FM encoder to 470 + DS. Tracking head and Index. Sometime hoping to put a 99 track HexDOS image into some ZIF PROM or SD on a small board with a smarter processor.

Which reminds me Dave, Steve Hendricks has also done alot with PICs and the like and mentioned interest in doing a controller/emulator ... Might help lighten the load for Leslie.

DOS/65 is also block oriented at the disk level.Reading 128byte blocks from 2048byte track which would suit SD mapping.

hobbyist.
600RevB:16K,2MHz,64x32,470,CEGMON
SuperKit:502,540B,542B,CEGMON, 8" and 5" FDDs
Cards:PE IO,6522 D-A-D, AY3-8910,ProgramGraphics,Color,UK101
WIP:Archive/Restore Util,HexDOS,FDD Emulator

RedskullDC
Posts: 41
Joined: Thu Jul 18, 2013 11:24 am

Re: FPGA Implementations

Post by RedskullDC » Wed Nov 22, 2017 1:09 pm

Hi All,

Just a note to say I haven't abandoned the project by any means.
Had a few big contracts at work over the last few months that have consumed an awful lot of time, but they are now coming to their conclusion.

Have been giving the disk interface a great deal of thought.
MK14HAK wrote:
Sat Aug 05, 2017 9:04 pm
Which reminds me Dave, Steve Hendricks has also done alot with PICs and the like and mentioned interest in doing a controller/emulator ... DOS/65 is also block oriented at the disk level.Reading 128byte blocks from 2048byte track which would suit SD mapping.
Sounds like a good idea, but I'd much prefer a solution within the fpga which maintains 100% software compatibility with real hardware.

So many options to choose from I'm afraid....All have their strengths and weaknesses.

Currently leaning towards the idea of using a NIOS co-processor to handle all the disk read/write functionality.
The free Altera University IP packages already include blocks to read/write to and SD card.

I already have some open source code which emulates a MB8866 (WD1792) floppy controller, and uses a NIOS instance to do the reading/writing to an SD card.
When work frees up a bit I'll see if that is a practical solution.

Cheers,
Leslie
Superboard II - RevD, 8Kb, DABUG monitor ROM.
FPGA C1P/C2/C4. 1-8MHz, 48Kb ram, CEGMON, 16KB Hires.

Post Reply