More pico-mac stuff

[Snial]

Congratulations!!!

Aaah, I forgot to add on the jump tables: 1.5kB. That takes it to ≈4774b, a bit shy of 5kB.

 

[cheesestraws]

Cortext M0+ doesn't support rotate left

No rotate left? How are the mighty fallen!

 

[Argyle Gargoyle]

This is really exciting - congrats Snial on a big landmark!

 

[joevt]

(val<<n)|(val>>(9-n))|(carry<<(n-1)) for byte

Did you test this yet?

I came up with this but I don't know if it's correct:

perl -E '
for ($i = 0 ; $i < 64 ; $i++) {
	# select some initial conditions
	$n = $i;
	$carry = 0;
	$val = 0b10000001;

	# do the ROXL.B
	$val |= $carry << 8;
	$n %= 9;
	$result = ($val << $n) | ($val >> (9 - $n));
	$carryresult = ($result >> 8) & 1;
	$result &= 0xff;

	# print the results
	printf "%2d %08b %d\n", $i, $result, $carryresult;
}
'

Should create a project in CodeWarrior that has a ROXL assembly function to compare the results with.

I used risu from qemu to generate random PowerPC instructions and compare the results of each instruction on a real CPU and an emulated CPU. It runs in Mac OS 7,8,9,or X. It needs updating/testing to work with 68K instructions (although it does have some code for 68K already).
https://github.com/joevt/risu

 

[Snial]

Hi @joevt,

Did you test this yet?

I actually just reasoned it so far . A normal ROL of n is: (x << n)|(x>>(8-n)). A ROL with carry will shift the upper bits just as much, but the next bit is filled with the carry (ie X on the 68000) and so the lower bits must be shifted by 1 more bit to make room. I could easily have an error, but it’ll be along those lines.

I came up with this but I don't know if it's correct:

perl -E '
for ($i = 0 ; $i < 64 ; $i++) {
    # select some initial conditions
    $n = $i;
    $carry = 0;
    $val = 0b10000001;

    # do the ROXL.B
    $val |= $carry << 8;
    $n %= 9;
    $result = ($val << $n) | ($val >> (9 - $n));
    $carryresult = ($result >> 8) & 1;
    $result &= 0xff;

    # print the results
    printf "%2d %08b %d\n", $i, $result, $carryresult;
}
'

I don’t know Perl, but it looks like it makes sense.

Should create a project in CodeWarrior that has a ROXL assembly function to compare the results with.

I used risu from qemu to generate random PowerPC instructions and compare the results of each instruction on a real CPU and an emulated CPU. It runs in Mac OS 7,8,9,or X. It needs updating/testing to work with 68K instructions (although it does have some code for 68K already).
https://github.com/joevt/risu

Ok, wow, thanks for that!

 

[BobDaAggie]

Wow. I am not a programmer but this is really fascinating. I am grateful for people like Snial who make big projects for us to play with.

 

[nicovr]

It was so interesting to find this thread and follow along the MØBius development process, instruction by instruction. @Snial, do you have any plans for additional development? Really nice work and write up.

 

[Snial]

It was so interesting to find this thread and follow along the MØBius development process, instruction by instruction. @Snial, do you have any plans for additional development? Really nice work and write up.

Thanks for the message, not ignoring you, will reply before too long.

 

[Snial]

It was so interesting to find this thread and follow along the MØBius development process, instruction by instruction. @Snial, do you have any plans for additional development? Really nice work and write up.

Thanks for the earlier reply. Great to get some feedback. The MØBius core emulator is written. It currently compiles, but doesn't properly assemble into an object file using the gcc-arm-none-eabi assembler (i.e. gcc-arm-none-eabi -c -o MOBius.o MOBius.s ).

Getting that done would be the next step. So, the way it compiles is similar to Cyclone68000. A 'C' program effectively acts as a macro assembler, so when it's run, it spits out ARM assembly code (in our case, Cortex M0+ assembly code). There are still a few errors in the .s but it wouldn't be too hard to solve.

 

[nicovr]

Thanks for the earlier reply. Great to get some feedback. The MØBius core emulator is written. It currently compiles, but doesn't properly assemble into an object file using the gcc-arm-none-eabi assembler (i.e. gcc-arm-none-eabi -c -o MOBius.o MOBius.s ).

Getting that done would be the next step. So, the way it compiles is similar to Cyclone68000. A 'C' program effectively acts as a macro assembler, so when it's run, it spits out ARM assembly code (in our case, Cortex M0+ assembly code). There are still a few errors in the .s but it wouldn't be too hard to solve.

Thank you for taking the time to reply! Very exciting to hear about the ongoing progress.