Low Level Operations using BIT Library

Vircop

Member
Licensed User
Longtime User
Ladies and Gentlemen,

i have to ask for a quick favor. My free time is currently quite limited, however i try to continue with my B4A-C64. (It's a C64 emulator written in B4A)

The good news is everything i coded so far compiles without problems. File Handling works (at least the memory dump looks after initializing the roms good)

I'm somewhat more the assembler guru so i'm trying to understand how byte operations (xor, and, shift etc) with B4A works. Since B4A is leaned towards java i know that there is no "real" unsigned char, basically a byte is always signed. That is of course no problem as long as you just carry "bytes" around, however it will not work with operations such as xor for example. So what i did is declaring basically all bytes as integers, because the BIT library expects Integers.

I have here for example the C64 opcode "BRK" in B4A. Before i end up in huge debugging i thought it would be a good idea to ask here before if that works.
I wrote that for the iOS before in C/C++ and the C code is after the B4A code.
Here's the code for that function - it's pretty much self explaining:

' Der Assembler-Befehl BRK erzeugt einen softwareseitigen Interrupt.
' Um den BRK-Interrupt vom Hardware-Interrupt unterscheiden zu können, setzt der BRK-Befehl das Break-Flag im Statusregister.
Sub BRK
Dim hb As Int
Dim lb As Int
Dim adr As Int
vars.PC = vars.PC + 2
hb = Bit.ShiftRight(vars.PC,8)
lb = Bit.And(vars.PC, 0xFF)
memory.PushStack(hb)
memory.PushStack(lb)
memory.SetFlagB
memory.PushStack(vars.PS)
adr = memory.AbsAdd(memory.peek(0xFFFE), memory.peek(0xFFFF), vars.c64true)
memory.SetFlagI
vars.PC = adr
End Sub

and here is my c-code (iOS)

void BRK(void)
{
//store PC in Stack
PC +=2;
c64byte hb = PC >> 8;
c64byte lb = PC & 0xFF;
PushStack(hb);
PushStack(lb);
//store Processor Status in Stack
SetFlagB();
PushStack(PS);
//Set new Programm Counter
c64ushort adr = AbsAdd(peek(0xFFFE), peek(0xFFFF), c64true);
SetFlagI();
PC=adr;
}

Comments?
 

Vircop

Member
Licensed User
Longtime User
Well it is a C64 Emulator (Not just this BRK function - it's just a part of many functions). You can run C64 Programs on your android device.
It's basically a personal hobby from me because when Commodore 64 was introduced i wrote quite a lot of comercial games for it.
That swapped into real life (for example my car license plate is C64) and i still enjoy coding for the C64. If all goes well i think i can present it here next months with the first games running.
 
Upvote 0

mc73

Well-Known Member
Licensed User
Longtime User
Well it is a C64 Emulator (Not just this BRK function - it's just a part of many functions). You can run C64 Programs on your android device.
It's basically a personal hobby from me because when Commodore 64 was introduced i wrote quite a lot of comercial games for it.
That swapped into real life (for example my car license plate is C64) and i still enjoy coding for the C64. If all goes well i think i can present it here next months with the first games running.

Cool! Having written myself, lot of stuff for the c64 in assembly, I will wait for your final product, if of course you let us test it :)
 
Upvote 0

MLDev

Active Member
Licensed User
Longtime User
Hi Vircop

I'm working on a similar app. It's a simulation of a cosmac elf computer with an 1802 processor. You won't have any problems with the Bit functions. One thing to keep in mind is speed. The fastest I can get the simulation to run is about the equivalent of a 1 MHz 1802 and the 1802 is a lot slower processor then the 6510 with the same clock frequency.
 
Upvote 0

Vircop

Member
Licensed User
Longtime User
Thanks for the replies so far. Honestly, speed was also my concern - i have to trial and error that. According to my calculations (and previous speed tests i performed with B4A compiled tests) it should be *OK*.

OK means it should be running in PAL mode (NTSC is the other option..) and the most critical stuff is the graphics as such. However, i optimized the graphics (such as having 320x200 windowed OpenGL with seperated C64 Keyboard and control lights) to that extend that it's very powerful. For example unlike other emulators i'm not walking in the way of

For X = 0 to 319
For Y = 0 to 199
...draw pixel with correct color
NEXT
NEXT

Instead of this i'm using a technology known from encoders. It basically just calculates the DIFFERENCES between two frames and updates this (depending on the clock usually just a few pixels unless you load a full screen for example the title screen with graphics)

This works pretty damn well and i had problems to "downsize" the speed on iOS devices. It was particular difficult to "count" a framerate if you only update a few pixels (frame rate on the target machine which is c64) so i ended up to write other CIA's (thats the timer stuff for keyboard, screen etc) according to my stuff. works pretty well.

The bottle neck will not be the emulator and gfx as such - but i'm almost sure i have to strip down SID (the sound chip) emulation to medium. That means sound will be "close" to c64 but it won't be perfect due to speed problems.
 
Upvote 0

Vircop

Member
Licensed User
Longtime User
Update: Forgot to mention it depends of course on what type of device you run that. On a 500 MHz it will not run. But i have hopes for my Galaxy Note 2 with multicore.
 
Upvote 0

Vircop

Member
Licensed User
Longtime User
Regarding the CPU speed.. as far as i remember the C64 in the PAL version runs with 0,985 MHz and 1,0xx in NTSC (xx was something in the 20's)

On what device are you running your 1802?
 
Upvote 0

MLDev

Active Member
Licensed User
Longtime User
I'm testing on a 1 GHz dual-core Acer Iconia. Just to give you an idea of the speed I'm getting with my simulator. The 1802 is a very slow processor. Most of the instructions are 16 clock cycles. The long jumps are 24 clock cycles. The fastest I can get the simulation to run is about 1 MHz (but I'm still working on getting it to run a little faster). I think the 6510 takes 2 to 7 clock cycles to execute an instruction so you're look at maybe the equivalent of 0.25 MHz or a little faster on the same hardware. The C64 clock speed was about 1 MHz.
 
Last edited:
Upvote 0
Top