sd cards & stuff

This is the right place to discuss on how to implement hardware vsync, adding a VIA or AY chipset, puting multiple roms, or how to design a new flash expansion card.
mmu_man
Flight Lieutenant
Posts: 322
Joined: Thu Sep 21, 2006 7:45 pm
Location: 26000 Valence, FRANCE
Contact:

Post by mmu_man »

Dbug wrote:Well, mapping a file of the sdcart directly into memory as if it was a cartridge is something that comes to mind ;)

My point is that some people are talking about doing some new floppy disk interface, have bus amplifiers, etc...

Having such a card with the additional VIA, SD card reader, and why not compability with Telestrat cartridges would be cool.
Yes that would be nice.
It should be possible to either partition the SD to have TAP files somewhere, and rom images elsewhere...
Or either just map them from files from the FAT from the card, but that would require a PIC or something else, as implementing FAT reading from an FPGA is likely huge.
On the C64 they have all these Action/Retro Replay cards with built in assembler and various utilities, having the equivalent on the Oric would be nice.
I don't know for C64, but Apple II had tricks to map expansion cards in memory in a standardized way, but we don't have this.
mmu_man
Flight Lieutenant
Posts: 322
Joined: Thu Sep 21, 2006 7:45 pm
Location: 26000 Valence, FRANCE
Contact:

Post by mmu_man »

mmu_man wrote:But if you want to use it differently the last thing to do is to map to an already used location!
Of course if it's only changing the unused midi bits to something else, as long as the rest is unchanged it should work.
highwayman
Flying Officer
Posts: 148
Joined: Fri Oct 12, 2007 8:08 pm

Post by highwayman »

carlsson wrote:If I understand correctly, the freezer carts on the C64 are possible due to a special memory map inherited from the somewhat obscure gaming console Ulti-MAX Machine.
that's wrong because the c64 came first and the max was intended to follow as a cut-price version.

to make a freezer you need to map the cartridge over the rom (we can do that) and then trigger an NMI.

then you also need to map a bit or 2 to reverse the change & continue the system.
finally, you need to write your code to make as little use of the stack as possible.

i could design the hardware but i really dont see the point.
highwayman
Flying Officer
Posts: 148
Joined: Fri Oct 12, 2007 8:08 pm

Post by highwayman »

mmu_man wrote:
highwayman wrote:it's probably better to map it to one of the usual places, $310 or $320 etc,
but do the bit usage from scratch.
A base principle of compatibility dictates the opposite.
If you use the same bits then map to the same place so it should work unchanged.
But if you want to use it differently the last thing to do is to map to an already used location!
whilest that's true,
looking at the various bits of data i have it looks like no matter what you do your gonna mess up something - some disk interface to be exact.
:roll:
thanks to crap partial address-decoding on a lot of those things - something that's always disgusted me as an engineer,
it's damned near impossible to find a block of bytes in the 300 area that "something" isnt sitting on or writing through.
:x
highwayman
Flying Officer
Posts: 148
Joined: Fri Oct 12, 2007 8:08 pm

Post by highwayman »

mmu_man wrote: It should be possible to either partition the SD to have TAP files somewhere, and rom images elsewhere...
Or either just map them from files from the FAT from the card, but that would require a PIC or something else, as implementing FAT reading from an FPGA is likely huge.
you really dont know what this is about do you?
go look at the iec2mmc link at the start of the thread.

to bring you upto speed,

there is an atmel microcontroller(a mega32!!) running 10 times faster than the oric 8)
it handles low-level card mapping and FAT16/32 layer.

that removes the overhead from the oric and makes it damned fast.
the oric just asks the atmel for a file by name or for a directory listing and the atmel streams the binary into the extra via on the oric.
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

highwayman wrote:to make a freezer you need to map the cartridge over the rom (we can do that) and then trigger an NMI.

then you also need to map a bit or 2 to reverse the change & continue the system.
finally, you need to write your code to make as little use of the stack as possible.

i could design the hardware but i really dont see the point.
Well, I can see two applications:
1) Allow the ripping of protected games. You let the game load, you freeze, save the memory on the sdcard/microdisc, and analyze/crack on the pc.
2) Do a post mortem examination of something you coded when it crashed.
JamesD
Flight Lieutenant
Posts: 358
Joined: Tue Nov 07, 2006 7:38 am

Post by JamesD »

highwayman wrote:you really dont know what this is about do you?
go look at the iec2mmc link at the start of the thread.

to bring you upto speed,

there is an atmel microcontroller(a mega32!!) running 10 times faster than the oric 8)
it handles low-level card mapping and FAT16/32 layer.

that removes the overhead from the oric and makes it damned fast.
the oric just asks the atmel for a file by name or for a directory listing and the atmel streams the binary into the extra via on the oric.
And once again, you are trading one protocol for another and the 6502 can only accept data at a certain speed anyway.
highwayman
Flying Officer
Posts: 148
Joined: Fri Oct 12, 2007 8:08 pm

Post by highwayman »

the 6502 would run a tight indexed loop reading from 3xx and writing to the start-address+x,
it would probably do it with interupts disabled.

if that is too slow for you then i feel sorry for you because that's as fast as it gets without hijacking the bus with an external dma system and it's also faster than any existing drive.

i could do dma - sure.
it's not so hard.
but it restricts the interface.

it's also a shitload more bus wiring and a bigger atmel with a lot more pins - i'd need atleast 4 maybe 5 8bit ports on it.
this then leads to being forced to use large surface-mount packages too.

if it comes doiwn to dma = 1 second load time and non-dma taking 2-3 seconds for a 40k block i think most people could wait.
highwayman
Flying Officer
Posts: 148
Joined: Fri Oct 12, 2007 8:08 pm

Post by highwayman »

Dbug wrote:
highwayman wrote:to make a freezer you need to map the cartridge over the rom (we can do that) and then trigger an NMI.

then you also need to map a bit or 2 to reverse the change & continue the system.
finally, you need to write your code to make as little use of the stack as possible.

i could design the hardware but i really dont see the point.
Well, I can see two applications:
1) Allow the ripping of protected games. You let the game load, you freeze, save the memory on the sdcard/microdisc, and analyze/crack on the pc.
2) Do a post mortem examination of something you coded when it crashed.

what games?

apart from damsel-in-distress and some french stuff like honey-kong that loaded over the stack i sorted everything with oricmon from pss back in the day.
JamesD
Flight Lieutenant
Posts: 358
Joined: Tue Nov 07, 2006 7:38 am

Post by JamesD »

highwayman wrote:the 6502 would run a tight indexed loop reading from 3xx and writing to the start-address+x,
it would probably do it with interupts disabled.

if that is too slow for you then i feel sorry for you because that's as fast as it gets without hijacking the bus with an external dma system and it's also faster than any existing drive. ...
I feel sorry for you? Oh please...

This has nothing to do with DMA. Just how do you think a block of data will be read from an SD card directly? All you have to do is clock the serial connection fast enough to transfer data as fast as the CPU can read or write without testing a ready status. The block transfers will be fast for both interfaces but both have a protocol overhead where the CPU has to send commands, read the response and send more commands.

The microcontroller *will* save you some clock cycles and be faster loading by taking care of reading the blocks without the CPU having to calculate where the next block is. But remember, this is a 64K computer and part of that memory will be taken up by DOS. If you look at the block size on an SD card you'll realize that you won't have to find that many blocks when loading a program.

A quick look at the speccy SD interface will show that both should load at what appears to be nearly instantaneous speeds.
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

About interruptions being off, and assuming there is a DOS... well, in the demos the first thing we do is to shut out the DOS entirelly, and talk to the disc controller using direct disc, track, sector notation.

The layout of the disc is written by Tap2Dsk/MakeDsk, so we are not even using filenames. It boots, read the bootsector, then loads the rest entirelly bypassing the DOS. This is important because it give us nearly 16 more kb of memory.

Now for the speed, technically Microdisc speed was good enough. The faster the better, but the most important is to have something reliable and compatible with existing devices. (Or to have the possibility to have a compatibility mode perhaps, by 'mounting' files that are .DSK as emulated disks.)

Or had you another idea on how the SD Card would be used ? With a custom DOS ?
mmu_man
Flight Lieutenant
Posts: 322
Joined: Thu Sep 21, 2006 7:45 pm
Location: 26000 Valence, FRANCE
Contact:

Post by mmu_man »

Ideally it would have a 2-lines LCD (like some other hw I've seen), and buttons to change the current dsk and tap file (one on each line)...
highwayman
Flying Officer
Posts: 148
Joined: Fri Oct 12, 2007 8:08 pm

Post by highwayman »

mmu_man wrote:Ideally it would have a 2-lines LCD (like some other hw I've seen), and buttons to change the current dsk and tap file (one on each line)...
that's been covered, there is already a project that does that.
JamesD
Flight Lieutenant
Posts: 358
Joined: Tue Nov 07, 2006 7:38 am

Post by JamesD »

Dbug wrote:About interruptions being off, and assuming there is a DOS... well, in the demos the first thing we do is to shut out the DOS entirelly, and talk to the disc controller using direct disc, track, sector notation.

The layout of the disc is written by Tap2Dsk/MakeDsk, so we are not even using filenames. It boots, read the bootsector, then loads the rest entirelly bypassing the DOS. This is important because it give us nearly 16 more kb of memory.

Now for the speed, technically Microdisc speed was good enough. The faster the better, but the most important is to have something reliable and compatible with existing devices. (Or to have the possibility to have a compatibility mode perhaps, by 'mounting' files that are .DSK as emulated disks.)

Or had you another idea on how the SD Card would be used ? With a custom DOS ?
If you bypass DOS you have to emulate the disk hardware somehow. You can use a microcontroller to do that but remember... the microcontroller has to run fast enough to do all required operations at least as fast as the CPU will expect data. That means it has to execute a lot of instructions behind the scenes. That's easy for a C64 interface that's slow but as you crank up the interface speed and increase the complexity of what it has to do you have to speed it up accordingly.

There are disk emulators in hardware that could be modified to look like an oric drive but it will cost more.
highwayman
Flying Officer
Posts: 148
Joined: Fri Oct 12, 2007 8:08 pm

Post by highwayman »

i had no intention of any complex dos,

just something similar to tape handling plus a dir command.

load"filename"
save"filename"

keeping it simple.
Post Reply