| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Arduino-based 1541 emulator. Possible?
Talking about Arduino with an hw-hacker father of a friend, i started to thinking about on how to build a full-compatible 1541 clone (6510, cia, ram, etc...) using Arduino hw.
I found this 6502 emulator:
http://www.df.lth.se/~richard/6502emu2.pde
May be possible to build a full sd card reader fully 1541 compatible (for low level drive programming)? |
|
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
anything is possible, if the Arduino has possibility for interfacing to the C64. (user/serial ports)
i suspect it has not, and you have to solder a usb interface to the c64 no ? |
| |
lft
Registered: Jul 2007
Posts: 369 |
Quoting Flavioweb
I found this 6502 emulator:
http://www.df.lth.se/~richard/6502emu2.pde
This 6502 emulator is not cycle-exact. You would probably have to write a 6502 emulator in assembly language. This could very well be possible on a 20 MHz AVR, but don't forget you also have to emulate four 16-bit latched timers that are updated every microsecond.
SIDwave: Whatever the problem is, it's not the electrical interfacing. |
| |
Fierman
Registered: Feb 2002
Posts: 85 |
interfacing is the least of your problems. timing and speed are, and you can just forget about using an older atmel based arduino for this purpose. it won't do. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
I also doubt that it's possible at all with 20 MHz.
There will be lots of issues concerning updating all internal state (as lft said) while operating in a very tight serial input-to-output response time frame.
We're talking about less than 20 AVR cycles per 6502 cycle for emulation of not only the 6502 but also a few other chips and glue logic here.
Better go for something faster. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
<Post edited by chatGPZ on 22/4-2013 21:19>
ppl have tried it with faster (100mhz) embedded systems - with little success. the problem is that the timing must be cycle exact in relation to the "outside world" - which is close to unpossible unless you have virtually "unlimited" resources.
or if you just want to hear that it can be done, easily - ask jim drew on lemon =) |
| |
WVL
Registered: Mar 2002
Posts: 902 |
I've got some experience with AVR's and there's no way you could do an emulation of the 1541 hardware on an Arduino (with AVR chips). You could probably do an IEC emulation and support generic load/save/getbyte commands, but that would be about all. Another problem is the amount of memory that's available : the Nano and Uno only have 2KB of memory, the Mega still only has 32KB... Having no memory means you have to read really fast from SD at the same time when you have to be really precise with your timing to communicate with your 64, impossible.
I even doubt it would be possible with the new Due that has a cortex M3 @ 84MHz, and that one also only has 96KB, still not even close enough to hold a single .d64..
Forget it.
It's not for nothing that the ultimate and chamelon are FPGA based.. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting Groepazthe timing must be cycle exact in relation to the "outside world" - which is close to unpossible unless you have virtually "unlimited" resources.
This sounds a bit funny. Care to elaborate? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
"This sounds a bit funny. Care to elaborate?"
just a failed attempt to say "We're talking about less than 20 AVR cycles per 6502 cycle for emulation of not only the 6502 but also a few other chips and glue logic here. Better go for something faster." :=)
PS: http://www.forum64.de/wbb3/board65-neue-hardware/board284-masse.. |
| |
Skoe
Account closed
Registered: Jan 2008
Posts: 34 |
I started to do it with an XMOS at about 400 MIPS shared among 8 Hardware-Threads some years ago (This one: XS1-L6A-64-TQ48). It was a mixture of C Code and Assembly. The I/O-Timing was sub-cycle accurate (+/- 100 ns AFAIR, compared with a logic analyzer to the real thing) and many fast loaders worked already. But only the ones that used the subset of the VIAs I implemented ;)
When I started another refactoring of my code I lost the patience and suspended the project - possibly forever.
What I can say today: I used less than 50% of the processing power and the code wasn't well optimized. So it is quite sure that it is doable on that controller. But I am sure it is not possible on < 100 MIPS with a compatibility of e.g. a 1541U. Today I think the cheapest solution that would be no pain in the ass to implement (compared to the evilness of sub-µs realtime on a controller) with > 99% compatibility could be based on a low-cost ARM controller (e.g. LPC13xx) for high-level tasks and a very small FPGA for CPU/VIAs/Head etc.
But as there is the 1541U/Chameleon for high compatibility and the sd2iec/arm2iec for low cost I'm not interested in another solution anymore. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting Groepazif you just want to hear that it can be done, easily - ask jim drew on lemon =)
Trying to ignore that guy, he uses to claim having done all sorts of drive feats but _always_ fails to deliver code or details, taking forever to find lost source codes etc. |
| |
Moloch
Registered: Jan 2002
Posts: 2928 |
Quote: Quoting Groepazif you just want to hear that it can be done, easily - ask jim drew on lemon =)
Trying to ignore that guy, he uses to claim having done all sorts of drive feats but _always_ fails to deliver code or details, taking forever to find lost source codes etc.
yes, thats the reason groepaz left that smiley :D
that guy can't be believed for anything |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
Would it be possible on a Raspberry Pi? |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
The problem with bigger systems like the Raspberry Pi is that you have to jump through a few hoops to get reliable real-time behaviour. The main issues are the cache and variable timing due to DRAM access. The ARM CPUs used though should have scratchpad memory in the order of 32 or so kB for fast deterministic access. Might be possible, but it won't be easy. There might be more surprises on the GPIO path. Good idea though to suggest Raspberry Pi. |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
and i must repeat myself: you need interface to C64. usb/par port, else forget this! |
| |
WVL
Registered: Mar 2002
Posts: 902 |
The new beaglebone would probably be better, but realtime stuff will still be a problem...
Better stick to a combination of an AVR/Atmel/whatever cpu for high-level non-realtime stuff and an FPGA for the realtime hardware emulation imho.. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
just wait for jim to prove you wrong, all of you! |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: and i must repeat myself: you need interface to C64. usb/par port, else forget this!
Most (all) embedded platforms have GPIOs, you need 3 (data, clk, atn) + some buffers and level converters. Now drop it, compared to timing problems HW interfacing is nothing. |
| |
CreaMD
Registered: Dec 2001
Posts: 3057 |
So if I get it right, for emulation you need precisely definable logic with exact controllable timing at all times. And this is the reason why 1541 emulation was never mad on PC, because there is no possibility to have 100% control over timing, even when booting into dos (coz every machine ha different specs and speeds of ram.. and various idiotic processor hacks for instruction fetching and all that crap.
hm? |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
You can do it on x86. With fast enough CPU and an RTOS guaranteeing CPU time etc. Or by doing your stuff in DOS/BIOS and disable instruction and memory caches to get complete control over timing. Fast enough CPU using a high precision timer would suffice. But in a "normal" OS environment like Windows, Linux or Mac OS the timing will be too jittery. You might be able to do it by scheduling a timer interrupt at a really high priority as a kernel driver/module. |
| |
CreaMD
Registered: Dec 2001
Posts: 3057 |
Jackasser.. thanx. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
I think something like this :
http://www.adafruit.com/products/451
plus an arduino with an LCD (for selecting .d64) and SD reader could make a nice 1541 emulator |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quoting WVLI think something like this :
http://www.adafruit.com/products/451
plus an arduino with an LCD (for selecting .d64) and SD reader could make a nice 1541 emulator
That's a tiny FPGA. 22kLE isn't much. and not putting the full drive emulation into the FPGA is probably going to make stuff more complicated. Remember, you still need to act on 1 us events and synchronize that with your cycle exact emulation running asynchronously in software.
It might be cheaper in material costs though, but that only matters in high volumes. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
I think the ultimate I doesnt have a lot more logic elements? also the ultimate needs to emulate a cpu in the fpga aswell...
Basically all your arduino/whatever cpu has to do is let the user select an image and transfer it to the FPGA's memory..
Just checked, the ultimate I has about 5500 logic cells, while this cyclone II has 22000! that's 4x more than an ultimate I! |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quoting WVLI think the ultimate I doesnt have a lot more logic elements? also the ultimate needs to emulate a cpu in the fpga aswell...
Basically all your arduino/whatever cpu has to do is let the user select an image and transfer it to the FPGA's memory..
Just checked, the ultimate I has about 5500 logic cells, while this cyclone II has 22000! that's 4x more than an ultimate I!
Actually you're right, sorry. I guess I'm just spoilt by more high end ones. ;)
So why not run the full emulation in the FPGA? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
"You might be able to do it by scheduling a timer interrupt at a really high priority as a kernel driver/module."
and thats precisely what openCBM does :)
and i dont think putting parts of the emulation into an FPGA and another part into software is a good idea or would save timer and/or money. once you have all the other chips in the fpga, adding the cpu aswell is least of all problems :) |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
There is the 1541 Ultimate. Where's the problem and what did i get wrong? Or do we just urgently need some more flaky ghetto-solutions? :-) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: "You might be able to do it by scheduling a timer interrupt at a really high priority as a kernel driver/module."
and thats precisely what openCBM does :)
and i dont think putting parts of the emulation into an FPGA and another part into software is a good idea or would save timer and/or money. once you have all the other chips in the fpga, adding the cpu aswell is least of all problems :)
Oh does opencbm support custom drivecode? I thought it only implemented iec which more or less is possible to implement in user space since the protocol is clocked. Anyway, cool if it does support custom drive code! :) |
| |
CreaMD
Registered: Dec 2001
Posts: 3057 |
Groepaz? So is there chance to have "true drive emulation" on stock PC that way? |
| |
Kisiel
Account closed
Registered: Jul 2003
Posts: 56 |
True drive emulation is not possible :)
http://projekt64.filety.net/index.php?dir=UK1541/&file=Level%20..
On this short presentation you can find vectors calculated in drive (UK1541) so this means cortex is enough to have true drive emulation. Old board is only to have IEC bus, VIA is removed.
Have another dream guys :P |
| |
CreaMD
Registered: Dec 2001
Posts: 3057 |
Kisiel, I need it explained to me, as to a child. I don't undesrstand what is cortex. And also don't get if you mean that emulation actually is possible on stock PC (without hadware hacks), or not. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
"Oh does opencbm support custom drivecode? I thought it only implemented iec which more or less is possible to implement in user space since the protocol is clocked. Anyway, cool if it does support custom drive code! :)"
not really "custom" (as in not user defined) - but it uploads own drivecode for the "fast" and "warp" type of transfers.
"So is there chance to have "true drive emulation" on stock PC that way?"
sure possible - but not the way you'd possibly want it to be (it'll block the pc)
and "cortex" is the marketing term for a certain ARM core/controller type (similar to what you'll find in many smartphones or netbooks) |
| |
Kisiel
Account closed
Registered: Jul 2003
Posts: 56 |
Cortex ????
one of ARM family http://en.wikipedia.org/wiki/ARM_architecture , thumb 2 only, small RAM and ROM.
I don't know what is STOCK PC, you have VICE on "stock PC" and for drive emulation one program for dos.
This topic is about Arduino 1541 emulation (ATmega8, ATmega168, ATmega328, ATmega1280.), so I think it's not possible but is possible on Cortex as I proved in video presentation. |
| |
CreaMD
Registered: Dec 2001
Posts: 3057 |
Thanx for explanation Kisiel. I seemed like if you were replying on my post, that's why I asked. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
That video doesn't prove much. Implementing some custom serial protocol is one thing, actually providing full compatibility for all types of disk access, speeders and custom routines another.
That said, i'm not doubting it's possible with an ARM CPU, just that this video feels like those dubious grainy blurred UFO "proof" things. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
hehe, i stopped watching video "proofs" of whatever years ago, although some of them at least have some entertainment value =)
and what krill says :) (actually supporting typical demo stuff is on the easier side of things, as that usually involves async protocolls anyway and thus timing isnt all that important - now try running some copyprotected original games on it =P) |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Maybe the Raspberry Pie is more suited..?
LFT has done a cross development suite for his own use. (asm + tools run on RP, connected to C64) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Scroll up, Raspberry Pi has already been discussed to some degree. |
| |
Kisiel
Account closed
Registered: Jul 2003
Posts: 56 |
its not sd2iec multi protocol emulation. it's cycle exact 6502 core with VIA emulation (4kB RAM,16kB ROM, timers, SOE handling etc). So far no illegal opcodes.it took me half year to code this emu. Now i am working on stage 2, sd to gcr. see new prototype on Silesia Party 7 as other guys.
Thanks for support but topic is Arudinio not UK1541. |
