sd cards & stuff

[JamesD]

Except the RDY pin which IIRC can be used to step the cpu is just grounded, doesn't come from the ULA.
Besides, the ULA can't stop doing the display, and the cpu will probably not like loosing it's clock. It can be done maybe but would need complex circuits to make sure it's safe (cf http://www.6502.org/mini-projects/clock ... ching.html ).

Hmmm... I'd have to look at the schematic. Either the ULA has to pause the CPU or the buss runs at double speed and the ULA and CPU alternate clock cycles.
It may not be possible without some cutting and soldering and I don't think people would find that acceptable.
It would be a possible enhancement if someone implemented the ORIC in an FPGA though.

I'm interested to see what alternatives people come up with. It wouldn't hurt to have a few choices.

[Dbug]

Hmmm... I'd have to look at the schematic. Either the ULA has to pause the CPU or the buss runs at double speed and the ULA and CPU alternate clock cycles.

I guess you can read the existing documentation
http://oric.ifrance.com/oric/hardware/ula.html

Mike Brown, Fabrice Frances and others have made quite extensive research on all that, and there is also the passionoric site with a VHDL implementation of the ULA.

[JamesD]

Hmmm... I'd have to look at the schematic. Either the ULA has to pause the CPU or the buss runs at double speed and the ULA and CPU alternate clock cycles.

I guess you can read the existing documentation
http://oric.ifrance.com/oric/hardware/ula.html

Mike Brown, Fabrice Frances and others have made quite extensive research on all that, and there is also the passionoric site with a VHDL implementation of the ULA.

Thanks for the link!

From that page:

The ULA performs several "visible" tasks which are closely integrated. These are:-

o Address Decode Logic Select lines for VIA chip, ROM, RAM areas of memory subject to state of ~MAP signal.

o Bus Clock signal production Division of 12MHz source clock into 1 MHz processor clock, internal 6 MHz dot clock

o Memory Multiplex (6502 versus Video arbitration) Interleaving of access to DRAM on two halves of 6502 cycle, one half to a single 6502 access, the other to one (or, in lores/text two) video accesses. Further multiplex of 16 bit addresses to 8 bit Row and Column format for DRAM

o Video signal production Acquiring video data from DRAM, conversion to pixel data via character sets (for lores modes), output as RGB ink and paper values Provision of sync signals for display device

o Memory Refresh Side effect of rapid sequential access to DRAM by video circuitry, causes every row to be guaranteed to be read within the required time.

o Control/Sequencing Externally, provides ~RAS ~CAS and R/~W control signals for DRAM along with row and column addresses from multiplexer. Internally sequences movement of data through ULA

So there is no DRAM refresh other than the side effect of updating the video. The 6502 and video refresh take place on alternate cycles.

That means an FPGA could use cycles unused for video refresh to support DMA *if* there are enough of them. If a RDY line were added to the CPU it could run at double speed part of the time.

Too bad they didn't have all address and data lines from the CPU go through the ULA. Then a full 12MHz could be used transparently to the CPU.

[mmu_man]

I'm not sure if it's the same as the one from Torlus (cf. silicium.org forums).
I recall seeing some FPGA AppleII (GS?) project somewhere also, I hope they join forces to share stuff.

[JamesD]

There are several Apple II's in FPGA but I haven't seen one that was 100% complete... yet.
http://www.mirrow.com/FPGApple/

BTW, there is also an MMC interface for the Apple on that site. It boots just like any other Apple drive so the DOS is bootstrapped from the device.
It uses a CPLD and a microcontroller. The author may be able to provide some tips.

[highwayman]

interest - good.

a few things i should point out - i'm looking at things with an open mind with regard to working in the oric - end goal would be an sdcard system *internal* to the oric.

but first - that digital tapedeck.
it records & plays samples.
it will work on the oric because it isnt system/format specific.
all you would need to do is put a pair of jumpers in the oric to bypass the analog circuits on the tape-socket.
saves will go fine as long as you give them a name,
loading would require the use of the lcd screen & select buttons.

but that dont interest me - i just mentioned it for others.


now as for the IEC system.
i see it like this, it's compact, handles fat,
handles translation to look like a floppy but be big like a hd,
and it's a serial interface.

so the interface is great,
the firmware could do with some tweaking to support the different header but that's easy.

the only thing i see is porting the IEC stuff to the oric.
there isnt much to it, just loading & saving & listing (loading to the screen via a string-printing buffer)

it's not dos, it's no competition for dos - far simpler.
but if all you want is a collection of games on sd and a quick way to select & load them it will do fine.
that's all i want - to convert all my tapes especialy my modded ones and homemade stuff to sd and build them in.

true - it wont stream bytes or do other clever stuff - but most people dont need that.
but again - the interface is simple.
infact the whole circuit is so simple i intend to try & build one into a usb-sdcard reader casing.

[JamesD]

interest - good.

a few things i should point out - i'm looking at things with an open mind with regard to working in the oric - end goal would be an sdcard system *internal* to the oric.

I think we are both in agreement that internal would be best. Too bad they soldered in so many of the chips or the machine would be a hackers dream.

but first - that digital tapedeck.
it records & plays samples.
it will work on the oric because it isnt system/format specific.
all you would need to do is put a pair of jumpers in the oric to bypass the analog circuits on the tape-socket.
saves will go fine as long as you give them a name,
loading would require the use of the lcd screen & select buttons.

but that dont interest me - i just mentioned it for others.

One thing that does concern me about such a unit is that different machines use different transfer rates and it would need to be able to handle the rate of whatever system you attached to it.
Just something people should keep in mind if they want to attempt to use that as a basis.

now as for the IEC system.
i see it like this, it's compact, handles fat,
handles translation to look like a floppy but be big like a hd,
and it's a serial interface.

so the interface is great,
the firmware could do with some tweaking to support the different header but that's easy.

the only thing i see is porting the IEC stuff to the oric.
there isnt much to it, just loading & saving & listing (loading to the screen via a string-printing buffer)

it's not dos, it's no competition for dos - far simpler.
but if all you want is a collection of games on sd and a quick way to select & load them it will do fine.
that's all i want - to convert all my tapes especialy my modded ones and homemade stuff to sd and build them in.

true - it wont stream bytes or do other clever stuff - but most people dont need that.
but again - the interface is simple.
infact the whole circuit is so simple i intend to try & build one into a usb-sdcard reader casing.

So rather than an entire DOS just forwarding commands like the C64.
Well... to be honest... the C64 disk setup was kinda ugly to work with and a lot of people used a "Wedge" just for that reason. But it does the job.

The interface (serial port) could also be implemented by itself and you could attach actual C64 drives which are readily available.
There is source code out there to add the same burst transfers that were on the C128 to the C64. It might be a good beginning point for a driver.
Not sure... didn't look through it.
<edit>
You can find the info here:
http://www.cs.tut.fi/~albert/Dev/burst/

[highwayman]

that's an interesting link - bookmarked

now as for the tape-sim,
it handles any reasonable baudrate, the guy designed it from the begining to handle fastloaders & custom formats.
and i just found this:
http://www.ktverkko.fi/~msmakela/8bit/c ... ex.en.html



as for the main thing - found this:

http://www.ffd2.com/fridge/docs/c64-diss.html

[waskol]

There is an Amiga 500 about to be finalized with FPGA and about to be released, it is called "Clone-A".
It has been recently introduced at a meeting in germany and it is said that it was perfectly working .

[JamesD]

There is an Amiga 500 about to be finalized with FPGA and about to be released, it is called "Clone-A".
It has been recently introduced at a meeting in germany and it is said that it was perfectly working .

Just an FYI, Minimig (FPGA Amiga) code was released some time ago and bare boards have been selling on ebay for weeks.

[JamesD]

that's an interesting link - bookmarked

now as for the tape-sim,
it handles any reasonable baudrate, the guy designed it from the begining to handle fastloaders & custom formats.
and i just found this:
http://www.ktverkko.fi/~msmakela/8bit/c ... ex.en.html

Ya know... that connection combined with the simple C64 tape interface to the PC I posted the link to could be used as a reliable interface to the PC. No need for an add on serial port for a PC connection.

*IF* overlay RAM were available through another mod bootstrap routine could be loaded at standard tape speeds, then DOS could be loaded to overlay and then it could emulate a drive over the interface at a high baud rate. This would be similar to Drivewire for the Tandy CoCo. That uses the CoCo bit banger serial port so it might be faster than with the Oric but it would probably work. If the Oric ROM routines are set up to be overridden then tape images could be loaded at high speed from the PC as well.

as for the main thing - found this:

http://www.ffd2.com/fridge/docs/c64-diss.html

Actually, I've seen that one before. Surprisingly simple isn't it.

If you can get the interface to work you could use the same cable C64's and Plus/4's use to attach to the PC. There's already software to emulated a C64 drive out there.

Ultimately, there still needs to be a bootstrap loaded or new ROM and without a disk drive some sort of added control to make overlay RAM available.

[highwayman]

dealing with overlay is easy, but most people would scream at my methods
i'd replace the 16k rom with a 32k one,
then use a gal to gate the upper address-line based on the address-bus and a signal from somewhere.
i could have any combination of 1k,2k,4k,8k + whatever ram is left after in the 16k area.

the trigger is more tricky - map a bit to the 300 area?
you'd have to remember to disable the interupts before paging or just set the interupt vector in the paged rom to return or do something usefull.

i need to check some pinouts - maybe a 6510 could be used to get a free i/o port.
probably not possible though.

i did think some more on the IEC bus, it can be cut to shreds.
we dont need multi-drop or addressing or some of the other stuff - just a bi-directional syncronous port.

infact if it was syncronous with ack then there would be no delays or timing - it could run at the maximum speed permitted by the hardware/software.

i need to build one for the c64 first - then take it from there.
i ordered a sd-card reader yesterday for the casing & socket - i'll order an atmel microcontroller in a few days.
gonna try & build one into this!

[JamesD]

The 6510 isn't pin compatible with the 6502 and I believe it's based on the 65c02 so there may be some minor incompatibilities.

[highwayman]

yea, if i can remember that far back i think loriciels was big on using unlisted opcodes!
not that it stopped me breaking there dodgy loader that abused the stack space.

[carlsson]

As far as I know, the 6510 is a basic 6502 with an extra I/O port to allow it to bank switch ROMs over RAM. The number of illegal op-codes should be the same, and thus no extra official instructions not present in the original 6502. The 65C02 however is another story.