It works, but I would prefer a standard i/o.. 
PS: you may see a snip of the screen does not work properly as it continuously rewrites it (see the line with "4")..
pito:
It works, but I would prefer a standard i/o..
PS: you may see a snip of the screen does not work properly as it continuously rewrites it (see the line with "4")..
Could be because the screen scrolled up?
It's not a good way to continuously rewrite the whole screen.
Causes a lot of data to be transmitted.
And CBM's don't use ascii in their videomemory, it's petscii.
My check is a quick and dirty hack to convert it to ascii.
It doesn't cover all codes.
janost:
It's not a good way to continuously rewrite the whole screen.
Causes a lot of data to be transmitted.
..
Yea, sending deltas only will do better.. But nice to see it works. And faster than the original..
I'll build it on a 1284 and use the C64 ROMs. They are more stable than PET ROMs but exactly the same V2 Basic.
And they can run down to 2K RAM without problems.
Also it supports both color and mono text/graphics.
I use soft-SPI on the due because of hysterical reasons so the screen can be very much faster.
But it works
Here is the memorymap if you want to emulate a C64.
Or POKE something into your emulated C64.
C64 MemoryMap.rtf (185 KB)
The C64 has an 6510 inside. So we need to enhance the emulator somehow
Try to run this on the DUE, how long does it take..
5 REM TRIGONOMETRIC FUNCTIONS TEST 0..89 DEGREE
10 PH = 3.141592653/2.0
15 REM DEFINE ARCSIN AND ARCCOS
20 DEF FN ASN(X) = ATN(X/SQR(1.0-X*X))
30 DEF FN ACS(X) = PH-ATN(X/SQR(1.0-X*X))
35 REM TR, TD - TO RAD, TO DEG
40 TR = 3.141592653 / 180.0
50 TD = 180.0 / 3.141592653
55 REM INPUT IN DEGREE (1..89)
60 FOR D = 0 TO 89
70 T = SIN(TR*D)
72 T = COS(TR*T)
74 T = TAN(TR*T)
76 T = TD*ATN(T)
80 T = TD*FN ACS(T)
90 T = TD*FN ASN(T)
100 PRINT D; "="; T; " DELTA="; T-D
110 NEXT D
120 END
Not much difference to a 6502 besides the IO port at $0000 and $0001.
That IO port control memory mapping of the 64K RAM and ROMs
pito:
The C64 has an 6510 inside. So we need to enhance the emulator somehow
Try to run this on the DUE, how long does it take..5 REM TRIGONOMETRIC FUNCTIONS TEST 0..89 DEGREE
10 PH = 3.141592653/2.0
15 REM DEFINE ARCSIN AND ARCCOS
20 DEF FN ASN(X) = ATN(X/SQR(1.0-XX))
30 DEF FN ACS(X) = PH-ATN(X/SQR(1.0-XX))
35 REM TR, TD - TO RAD, TO DEG
40 TR = 3.141592653 / 180.0
50 TD = 180.0 / 3.141592653
55 REM INPUT IN DEGREE (1..89)
60 FOR D = 0 TO 89
70 T = SIN(TRD)
72 T = COS(TRT)
74 T = TAN(TRT)
76 T = TDATN(T)
80 T = TDFN ACS(T)
90 T = TDFN ASN(T)
100 PRINT D; "="; T; " DELTA="; T-D
110 NEXT D
120 END
I'll try.
The general way of measuring speed on a CBM is this.
FOR I=0 TO 1000:NEXT
That takes exactly 1 second on a 1MHZ 6502 in CBM Basic.
Make one I=1 to 10000 and clock it.
That will tell you the factor against the original.
Don't look blindly on my 84MHz DUE.
This runs equally well on any system that can support the memory.
I haven't used any of the DUE's fancies.
I do like to write the library's inline because most of the Arduino library's are such memory hog's.
Better to strip them down and include it in the sketch.
Ladyada isn't the best coder
I have attached my cpu.c and Arduino code to boot the C64 emulator in color.
I know it's not ok to put ROM's or BIOS code out in the open but in this case it might be ok?
The reason I use soft-SPI on the DUE is because it needs an exclusice connection to the ISP connector for SPI.
And that you can just stick a 1.8" or 2.2" TFT into one of it's headers if you run it soft.
DUE6502.ino (22.5 KB)
cpu.c (353 KB)
This takes 4.5sec on my system:
10 FOR I = 1 TO 10000
20 NEXT I
READY.
RUN
pito:
This takes 4.5sec on my system:10 FOR I = 1 TO 10000
20 NEXT I
READY.
RUN
That makes 10000/4500*1MHz or a 2.2MHz 6502
I don't want to the same on the DUE.
It will show a 10MHz 6502.
pito:
This takes 4.5sec on my system:10 FOR I = 1 TO 10000
20 NEXT I
READY.
RUN
Not a new line.
It needs to be written in one line.
10 FOR I=1 to 10000:NEXT
But I guess it's marginal.
janost:
pito:
This takes 4.5sec on my system:10 FOR I = 1 TO 10000
20 NEXT I
READY.
RUN
That makes 10000/4500*1MHz or a 2.2MHz 6502
But that is with exec6502(100); inside the "video and input loop" sending 1000bytes of video @115k2 continuously. So it must be much higher speed than the 2.2MHz. How to measure it then??.
pito:
janost:
pito:
This takes 4.5sec on my system:10 FOR I = 1 TO 10000
20 NEXT I
READY.
RUN
That makes 10000/4500*1MHz or a 2.2MHz 6502
But that is with exec6502(100); inside the "video and input loop" sending 1000bytes of video @115k2 continuously. So it must be much higher speed than the 2.2MHz. How to measure it then??.
Yes, it is.
You may have noticed that my exec6502 doesn't have any number, just empty brackets.
The emulator is written for PC and several hundred MHz of CPU and has to be slowed down.
I have removed that to make it run as fast as it can or exec6502(1).
You can't really measure with that video response.
Make it delta and it will perform better.
I think the 100 in the 6502exec is not about "delays", but it says "do 100 6502 instructions before returning from 6502exec".
With 1 it will do a single 6502 instruction, then it returns. So the higher number there the more time it spends in 6502 emulation..
Also, I think there must be a function which offers a char at a specific ram address to be printed into video ram..
Finding that point I can get rid of the video mess and hook the stuff similarly as the enhBasic does..
pito:
Also, I think there must be a function which offer a char at a specific ram address to be printed into video ram..
No and yes.
As I said before the OS prints through a function at $FFD2.
There is no way the OS knows that you are emulating it?
It puts chars in the videomem believing that you can see them.
I ran the enhBasic with above trigonometric test under arduino @16MHz (no video mess) and it took 84secs/
Then I ran it under the second system (also the enhBasic,no video mess) and it did it in 8.1sec. So my understanding is the second system's emulation speed is ~10x faster than the arduino @16MHz - based on your info it means 6MHz.
I doubt DUE can do that such fast..