FPGA Implementations

RedskullDC
Posts: 44
Joined: Thu Jul 18, 2013 11:24 am
Location: Sydney, Australia

Re: FPGA Implementations

Post by RedskullDC » Thu Jul 20, 2017 11:54 pm

Hi Steve,
Steve Gray wrote:
Tue Jul 11, 2017 3:30 am
but 16K is a lot to allocate...
Steve
I should have mentioned....

Only the first 8k is taken from system ram ($8000-$9FFF).
The second 8k is write only, and hides behind BASIC at ($A000-$BFFF).

Can always make it compatible with the Mittendorf board anyway.

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

RedskullDC
Posts: 44
Joined: Thu Jul 18, 2013 11:24 am
Location: Sydney, Australia

Re: FPGA Implementations

Post by RedskullDC » Fri Jul 21, 2017 12:26 am

Hi Dave, Jim, et al.
dave wrote:
Thu Jul 20, 2017 7:46 pm
w4jbm wrote:
Thu Jul 20, 2017 3:40 pm

I think there are ways around this but I remember following someone trying to get a "new" 5.25" drive working with their OSI on a mailing list back in the late 1980s and running into that.
There is a good article on using high density drives, including interface tweaks, adapter cables, and OS patches, in Peek(65) Vol 7, No. 12. The interface needs to be configured for an 8" drive (250 kbps) and so does the data separator (3 us window).

Dave
I went through all the newsletters and articles I could find on your site that related to disk drives.
That Peek65 V7N12 article was most informative.
Mark Csele's page at :
http://technology.niagarac.on.ca/people ... tific.html
has an interesting section on diagnosing OSI floppy drive issues which clarified a few things too.
(Like the drive continuing to write clock bits after the end of a sector till the index hole shows up again)

The drive density/rotational speed isn't a problem with the TEAC drive.
It can be jumpered to default to LOW/HI density or 300/360 RPM without requiring any signals from the cable to switch:
https://archive.org/details/Teac_FD55GF ... _1996_Teac

I'll probably use a 3.5" drive most of the time, but being able to read/write "real" 5.25" disks will be handy.

---
The code is pretty much done to write to disk at the 5.25" 125kHz rate.
That is the easy part, since it is all synchronised to a fixed clock.

Read code is more difficult, as the read clock needs to be derived from, and track, the input stream.
I'm thinking a state machine running at 8x (or 16x) the 125kHz clock rate to enable simulating the function of the one-shots in the data separator.....

Will start on the read code next weekend (real life permitting).

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

w4jbm
Posts: 23
Joined: Sun Jun 18, 2017 1:41 pm

Re: FPGA Implementations

Post by w4jbm » Sun Jul 23, 2017 8:48 pm

A step ahead of me as usual... :)

Work is keeping me hopping so I haven't had time to do anything lately...

RedskullDC
Posts: 44
Joined: Thu Jul 18, 2013 11:24 am
Location: Sydney, Australia

Re: FPGA Implementations

Post by RedskullDC » Thu Jul 27, 2017 12:52 pm

Hi All,

A minor snag...

The 6850 compatible UART in Grant Searle's code doesn't handle the PARITY modes.
It's simply ignores any configuration, and remains stuck in 8N1 mode.
Makes sense for the PC<=>USB TTL connection, but it's no good for reading/writing to a real disk drive which is 8E1 (I think?).

Anyway, I'm going to use Jonathan Kent's 6821 and 6850 modules, which *do* support all modes.
They'll need a bit of work done to work in the current design though.

---

I'm exploring another possibility for disk emulation as well.

I've hooked up an external SRAM to the DE0_CV board.

It's a Dallas DS1270, which is a 2MB x 8bit battery backed chip:

Image

It would be possible to save disk images to the SRAM in *any* of the popular size configurations.
4 x 512Kb disk images could be online at any one time.

Just need to write some simple 6502 code to be able to send/receive the disk images via the USB<=>TTL interface back to the PC/MAC.
Plenty of unused memory space in the $FXXX area where the routines could live.

The same SRAM setup could theoretically be attached to a "real" OSI board as well.

More to come...

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

stm
Posts: 43
Joined: Mon Oct 27, 2014 10:23 pm
Location: Germany

Re: FPGA Implementations

Post by stm » Fri Jul 28, 2017 8:28 pm

Leslie,
RedskullDC wrote:
Thu Jul 27, 2017 12:52 pm
Anyway, I'm going to use Jonathan Kent's 6821 and 6850 modules, which *do* support all modes.
They'll need a bit of work done to work in the current design though.
I'm interested in these 6821 and 6850 modules. Are they publicly available?

Thanks
Stephan
C1P Model 600 CPU 1978 REV B, 40K (8K original and 32K BillO memory expansion), RS-232
Maintainer of cc65 OSI target

RedskullDC
Posts: 44
Joined: Thu Jul 18, 2013 11:24 am
Location: Sydney, Australia

Re: FPGA Implementations

Post by RedskullDC » Fri Jul 28, 2017 10:38 pm

Hi Stephan,
stm wrote:
Fri Jul 28, 2017 8:28 pm

I'm interested in these 6821 and 6850 modules. Are they publicly available?

Thanks
Stephan
Yes, they are both open source.

They are components included in Mr Kent's "System09" project.

More info on that, and his other project can be found at his webpage:
http://members.optusnet.com.au/jekent/FPGA.htm

Latest version of system09 can be downloaded from:
http://opencores.org/project,system09
(Free, requires registration).

Loads of worthwhile code can be found on Opencores!

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

stm
Posts: 43
Joined: Mon Oct 27, 2014 10:23 pm
Location: Germany

Re: FPGA Implementations

Post by stm » Sat Jul 29, 2017 9:33 pm

RedskullDC wrote:
Fri Jul 28, 2017 10:38 pm
More info on that, and his other project can be found at his webpage:
http://members.optusnet.com.au/jekent/FPGA.htm

Latest version of system09 can be downloaded from:
http://opencores.org/project,system09
Got it, thanks!
C1P Model 600 CPU 1978 REV B, 40K (8K original and 32K BillO memory expansion), RS-232
Maintainer of cc65 OSI target

RedskullDC
Posts: 44
Joined: Thu Jul 18, 2013 11:24 am
Location: Sydney, Australia

Re: FPGA Implementations

Post by RedskullDC » Tue Aug 01, 2017 3:12 pm

Hi All,

Some minor progress...

Jonathan Kent's 6821 and 6850 modules are now wired up ok, just doing some preliminary testing.

Pic shows a simple BASIC program accessing the DISK PIA port A at $C001/$C002:
(For testing purposes, port A is wired up to the output LEDS)

Poke 49153,0 Select DDRA in control reg
Poke 49152,255 Set all bits to outputs
Poke 49153,4 Select DRA in control reg
Poke 49152,22 Set some DRA bits to output '1'

The last command :
Poke 49152,45 ($2D) is 00101101 in binary, which is the pattern seen on the leds:

Image

Give the 6850 a test out tomorrow, time permitting...

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

RedskullDC
Posts: 44
Joined: Thu Jul 18, 2013 11:24 am
Location: Sydney, Australia

Re: FPGA Implementations

Post by RedskullDC » Thu Aug 03, 2017 2:14 pm

Hi All,

Did some simple loopback tests of the 6850 this evening.
Was also able to load/save some programs via a USB<=>TTL cable to the PC.
Looks like both the 6850 and 6821 from Jonathan Kent are working ok in the design.

-----------------

Disk Emulation:
I wouldn't mind a bit of input here on what people would prefer to see first

I'll probably implement them all as time permits, since they all have benefits.

1. Interface to a real disk drive.
Pros: read/write real disks, compatibility with real OSI machines
Cons: requires some minor construction work. Simple adapter from the DE0_CV GPIO port to the disk drive via a level translator and a ULN2003 to drive the outputs. Needs some "fancy" coding for the data separator.

2. Interface to a Non-Volatile SRAM.
Pros: Allows read/write of disk images, data stays intact when machine powered off. Relatively easy to read the NVSRAM with a device programmer for loading/saving disk images. Coding relatively easy
Cons: Minor construction required. Again, GPIO port to a 40pin DIP socket.

3. Emulate the disk within the block RAM of the Cyclone V FPGA itself.
With the current design, there is enough free RAM in the FPGA itself to hold 2 x 40-track 5.25" disk images of 92160 bytes each.
Pros: Requires no construction work/modifications. Runs on a DE0_CV out of the box.
When tethered to a PC running Quartus II, it's possible to read/write the memory using the "In-system memory content editor" tool. This makes loading/saving disk images very easy indeed. Coding relatively easy.
(The disk dump utilities in "OSITOOLS.ZIP" could also be used to send a disk image back up the USB<=>TTL cable to a PC)
Cons: There isn't enough block RAM to emulate an 8" disk in the FPGA.
Disk images need to be loaded/saved at power-up, shut-down. (No worse than inserting/removing a real floppy though ;) )
Relying on the Q2 Memory tool makes the design less transportable to other platforms.

Is anyone else (apart from Jim) keen to actually take the plunge and use this project?

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

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

Re: FPGA Implementations

Post by dave » Thu Aug 03, 2017 4:22 pm

Leslie, this is amazing work, and is getting at something that could be really useful for folks with real OSI systems but without working disk systems.

Can I suggest a couple of additional options?

4. A SD-card interface. Perhaps if there's room in the FPGA, a small AVR or PIC (or 6502) compatible core, and use already available libraries to do the SD control, filesystem, and file format in firmware? The advantage is that this would be useful as a standalone card for systems that have no disk interface. An SD card would enable transfer of images from a PC without special software or hardware.

5. Wishful thinking, but a combination of options 1+4. A real disk interface (#1) plus a SD-card interface (#4), plus a UART on the disk interface side to recieve and transmit the serial stream to the OSI. This would give an extraneous encode-decode step in each direction, but would allow the design to be configured to use a real floppy with emulated OSI hardware, a controller+floppy for real machines without a controller, and a floppy emulator for machines with disk interfaces.

Keep it up!

Dave

Post Reply