Arduino 6502 emulator + BASIC interpreter

Projects Showcase
101

pito:
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 is ~10x faster than the arduino @16MHz.

I don't have the full history or background of EHBasic.

But Microsoft's basic, running on the CBM and Atari 8-bit, is way faster than EHBasic.
With higher precision.

Trust me. Those Basic versions are the fastest in history on 8-bit platforms.

102

It does not matter because both benchmarks were done under enhBasic. 1284p mighty 84secs, second system 8.1secs.
There is serial i/o in enhBasic, so the video does not interfere into the measurement..

103

pito:
It does not matter because both benchmarks were done under enhBasic. 1284p mighty 84secs, second system 8.1secs.
There is serial i/o in enhBasic, so the video does not interfere into the measurement..

Then measure it the same way on the C64?

No video to interfere?

104

I normally work on the NXP LPC platform.
But there aren't anything even close to the DUE on that platform.

So the DUE makes a great breadboard platform.
Even the Thumb ARM-assembly runs straight on the NXP ARM Cortex M0+

105

I cannot compare that under C64 even when run on both systems, as the video (not related to the emulation) messes heavily the results up..
The enhBasic is good for benchmarking (of the emulation speed) on various systems as the serial i/o there does not interfere too much.

106

pito:
I cannot compare that under C64 even when run on both systems, as the video (not related to the emulation) messes heavily the results up..

No, it doesn't?
Don't you just time it from start to ready?

You cant time things that are printing to the screen constantly?

Even the PC stopped decades ago timing things like that?

107

Unless some tricks applied I cannot do it easily with C64 as when I stop the video I cannot see the test has finished :slight_smile:
With enhBasic you may print start/stop and measure the elapsed time. No video buffer needs to be read.

108

Don't run my loop blind.

Make the "CPU" run more and the video less?

109

When you need to compare architectures/compilers running the cpu.c emulator then the best option is to use the enhBasic as it communicates via Serial only. So the error related to the communication with the emulated system (with Basic) is small.
The C64 rom communicates via video stream, where the stream takes a lot of time in comparison to the time spent in the emulator. That issue is the same for my Terminal printing, as well as for your tft video emulation.

110

pito:
When you need to compare architectures/compilers running the cpu.c emulator then the best option is to use the enhBasic as it communicates via Serial only. So the error related to the communication with the emulated system (with Basic) is small.
The C64 rom communicates via video stream, where the stream takes a lot of time in comparison to the time spent in the emulator. That issue is the same for my Terminal printing, as well as for your tft video emulation.

The EHBasic is basically the lower 8K of the MS C64 ROM set.

I don't know what you want to measure?
But I do know that its faster.

Using it is what differs.

111

janost:
I don't know what you want to measure?

People might be interested to see how the cpu.c emulator performs with avr, CM0, CMO+, CM3, CM4, pic32MX, pic32MZ, etc.. compiled with X, Y, Z compilers.. So when they want start to measure the enhBasic running a benchmark is the good option..

112

pito:

janost:
I don't know what you want to measure?

People might be interested to see how the cpu.c emulator performs with avr, CM0, CMO+, CM3, CM4, pic32MX, pic32MZ, etc.. compiled with X, Y, Z compilers..

That's why I put up the code for a C64 in textmode. :slight_smile:

Compile it on anything.

113

And your program completes in 1.5 seconds on the emulator running on the DUE :slight_smile:

114

By doing color on the CBM ROM's I now have 256 16-bit writes on every character write.

That sucks. Big time?

115

janost:
And your program completes in 1.5 seconds on the emulator running on the DUE :slight_smile:

Hard to believe :slight_smile:

116

pito:

janost:
And your program completes in 1.5 seconds on the emulator running on the DUE :slight_smile:

Hard to believe :slight_smile:

The videoemulation on the TFT only slows down the 6502 emulator when it writes something in videomem or colormem.

Otherwise is has no impact on the emulation and it runs at full speed.

117

I ran it on pic32mx Fubarino o'clocked 120MHz (compiled with chipkit's compiler, USB serial com), and the below trigo test took about 10secs (C64 V2 ROM). I only read the first half of the bottom line to eliminate video. So it seems there is an issue somewhere (provided mips is ~20% faster than arm and my clock is 30% more yours) :slight_smile: For example, if you do not switch CapsLock on, it returns in 1 sec as it does not run the code (the code is empty).. :slight_smile: Unless the mips compiler is a crap I would estimate 19.9 secs for your code in the DUE..

PS: The test for reference:

5  REM PITO'S TRIGONOMETRIC FUNCTIONS TEST 0..89 DEGREE
6  REM FOR C64 V2 BASIC ROMS
7  REM BASED ON WELLKNOWN "9 DEGREE" CALC FORENSIC TEST
8  REM ASIN(ACOS(ATAN(TAN(COS(SIN(9.0)))))) = 9.0 IN DEGREE
10 PH = 3.1415926536/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.1415926536 / 180.0
50 TD = 180.0 / 3.1415926536
55 REM INPUT IN DEGREE (0..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

READY.
RUN
 0 = .0708403071  DELTA= .0708403071
 1 = 1.00188405  DELTA= 1.88405439E-03
 2 = 2.00156704  DELTA= 1.56704057E-03
 3 = 3.00102166  DELTA= 1.02166273E-03
 4 = 4.00055188  DELTA= 5.51875681E-04
 5 = 5.00046232  DELTA= 4.62317839E-04
 6 = 5.99979405  DELTA=-2.05950812E-04
 7 = 6.99975351  DELTA=-2.46489421E-04
 8 = 8.00046608  DELTA= 4.6607852E-04
 9 = 9.00044075  DELTA= 4.40750271E-04
 10 = 10.0001669  DELTA= 1.66922808E-04
..
 84 = 83.9999204  DELTA=-7.96020031E-05
 85 = 85.0002601  DELTA= 2.60084868E-04
 86 = 86.0004052  DELTA= 4.05162573E-04
 87 = 87.0003106  DELTA= 3.10570002E-04
 88 = 88.0004901  DELTA= 4.90099192E-04
 89 = 89.0023091  DELTA= 2.30902433E-03

READY.
118

This is the version with transferring deltas only from C64 video RAM to the VT100 terminal (25 rows x 40 columns).
VRAM is a temporary video memory holding "old" characters. We compare the new RAM[] to VRAM and if a difference we print the new character at the VT100 [row,col] position.

Mind you have to have CapsLock on on your keyboard..

Works nice with VT100 in TeraTerm.

..
uint8_t VRAM[1000];

void VTposition(uint8_t row, uint8_t col) {
	Serial.write(27);
	Serial.write('[');
	Serial.print(row + 1);
	Serial.write(';');
	Serial.print(col + 1);
	Serial.write('H');
}

void setup () {
	Serial.begin (115200);
	Serial.println ("Booting the ROM..");
	reset6502();
	delay(1000);
	for (int i=0; i<1000; i++){
		VRAM[i] = RAM[i+1024];
	}
}

void loop () {
	int v_address = 0;
	for (uint8_t row=0; row<25; row++) {
		for (uint8_t col=0; col<40; col++) {
			if (Serial.available()) {
				curkey = Serial.read() & 0x7F;
				RAM[198] = 1;
				RAM[631] = curkey; 
			}

			exec6502(100);

			uint8_t petscii = RAM[v_address + 1024];

			if (VRAM[v_address] != petscii) {
				VRAM[v_address] = petscii;
				VTposition(row, col);	
				if (petscii<32) petscii = petscii + 64;
				Serial.write(petscii);
			}
			v_address++;
		}
	}
}
119

Looks like it got featured on Hackaday before it was finished.

120

Running on the ATmega1284P with internal 8MHz oscillator.

C64_1284.jpg
C64_1284.jpg800×450 120 KB