SAM2GB WILL BE DISCONTINUED FOR THE TIME BEING...
I tried to pick up where I left, but even with other games I am having problems with the characterdata as described in the NOCASH-emulator and the way I coded it. Anyone who has detailed info about the gameboy and its characterdisplay (even better someone who made an emulator may contact me.Right now I will start to code a ZX81-emulator for the CP/M.
I found out that the backgroundroutine uses so much time that it takes a while before data for the characterdisplay is filled. I have to call the backgroundroutine not so often. Luckily no emulation error or something like that.
I typed the characterroutine in a teksteditor to print it later. While doing I discovered 3 errors in the routine. I will fix the errors on the way back and see what I will get on the screen then.
The good news: It shows flashing characters (which it must) and I can still return to BASIC when exitkey is pressed.
The bad news: The characters are displayed almost randomly on the screen.
Well, it's time to fix that problem.
The gameboy holds 4 bits with 4 colours in an address, like this
+--+--+--+--+
|00|01|10|11|
+--+--+--+--+
The SAM holds 2 bits on the screen in an address in 16 colours, like this
+----+----+
|0001|0010|
+----+----+
So the value of the game boy should be transferred to this:
+----+----+ +----+----+
|0000|0001| |0010|0011|
+----+----+ +----+----+
or this when the start is at an odd pixel
+----+----+ +----+----+ +----+----+
|xxxx|0000| |0001|0010| |0011|xxxx| xxxx = unaltered
+----+----+ +----+----+ +----+----+
This will implicate that a left bit should be shifted 6 times and a right bit 2 times.
I made my code to shift in a right bit twice over the right (as mentioned), but also shifted my left bit twice and mirrored the value over the left. The colourvalues will become 0001 > 1000, 0010 > 0100 and 0011 > 1100, but I gave the colours on the SAM the same value, so you see no difference.
This gameboy value
+--+--+--+--+
|00|01|10|11|
+--+--+--+--+
becomes on the SAM
+----+----+ +----+----+
|0000|0001| |0100|0011|
+----+----+ +----+----+
or this when the start is at an odd pixel
+----+----+ +----+----+ +----+----+
|xxxx|0000| |1000|0010| |1100|xxxx| xxxx = unaltered
+----+----+ +----+----+ +----+----+
So far some screen explanation.
Also The CLUT was not set correctly, but I fixed that problem.
It keeps a man of the street!
A lot of snow is expected to fall, I will see how long my trip back home will take.
Wolfgang Haller has tested my latest PC-ZX serverprogram. SCR-files can now be loaded too over the ZX-PC Interface. (Thanks Wo)
Some extra time I spent on the ZX-PC Software. In theory the loading of SCR-files is possible.
On my way back yesterday I got a row, on my way to work this morning I got the entire screen working. I still made a small error by testing on a value 1 too high when end of line was reached, but I found the flaw. I think that I will be skipping the window screen to a later moment and start with the character display first so I can show the very first screen from the emulator soon.
The problem is that the background wraps around and the L-register is also a part of the vertical row-counter.
Well, it wouldn't be a challenge if all went smoothly!
Finally some progress!
(sigh)I started a complete new approach for the background. First I tried to place just 4 bits, then 8 bits (a row) and later 8 rows (a pattern). Not only did I get what I wanted, but also with some faster routine. Now a complete row of patterns and then a complete background.
The only option: try to make a seperate and simple backgroundroutine for first 1 pattern then a row then a complete background.
I think I have found the flaw. I checked a bit routine which must be run with every bit on the value of all 4 bits. But when the values are zero the routine ends before even starting. I must work it out again.
I found out that not the colours 12 to 15 but the colours 0, 4, 8 and 12 must be set.
The ZX-PC Interface is still in development, but can't be done in the train.
It was almost ready when the day ended. However it gave me again some ideas to work on the ZX-PC Interface.
Therefore the development of the SAM2_GB emulator will be discontinued for a small time (probably a week or 2).
The ZX-PC Interface will be added with a functionality to read MDR-files and SCR-files.
I am going to make a pixel based screen in MODE 4!
I also thought of a nice pixel drawingroutine. The routine will first collect a piece of the pattern (4 bits in 4 colours at once).
Then I decide whether the routine must place the pixel on a odd or even post.
Per pixel the routine will shift the bits out. All patternpixels are shifted out left, but
odd screenpixels are shifted in right and even screenpixels are shifted in left.
By this way i can quickly split 2 bits from four and also on the SAM the colours for the
left and right bit. I only must set the CLUT in 16 colours where :
colour 0 is also colour 15
colour 1 is also colour 14
colour 2 is also colour 13
colour 3 is also colour 12
In this way I am no longer bounded by 4 or 2 bits scrollers!
but I still haven't found what I am looking for (popquiz: Name the Band).
Luckily the SPC-Magazine came in yesterday. I read it in the train.
I am even thinking of making it a single bit routine. If I decide to do so I have ended all my display problems. Give me some time....
The last days I had no time to code in the train during my trips to Amsterdam.
I had some other things to make. Even better because I am sufffering a bit of a
coders-block (like writers have a writersblock). I am facing the dilemma of keeping
a MODE 3 screen or go to a MODE 4 screen. I saw the results of the background
on the screen. The width looks very compressed. Another problem is the Window
that can be drawn as an extra 'background'. It can be shifted out of place and the
4 bits mode I use now is to rough to give a nice screen. I am thinking of rewritting
the backgroundroutine to a 2 bit setting.
Instead of coding I played KLAVERJAS untill I was in Amsterdam.
I printed a new version from the Internet and stored it digitally on my laptop.
I will code again on my way home.
Unfortunately due to the MODE 3 screen the block is larger than width. I will make the screen in MODE 3, but
I might go for the slower, but more alike MODE 4 screen.
The advantage of setting four pixels at once made me decide to do it.
The shown format of the display is still almost the same size of a real Gameboy.
When placed in the center of the screen I can place additional info around the screen.
The background can be set per pixel. If I want to set 4 pixels at once I must set the background at
places dividable by 4. The background will therefore be a 4 bit scroller. For speed this works better.
The problem only occurs with horizontal scrolling games, so fixed screens and vertical scrollers can
work faster. Something to add for the future !!!!
but soon I grapped the iBook. The idea was to make a screen appear.
I had to set the VMPR right and set the screen using LMPR since the code run in uppermemory.
The problem: I only had an example made with screen setting in HMPR.
I altered the example and finally it worked in LMPR. I can now start the screenrefreshments.
I am still doubting ; shall I go for a fast but small screen in mode 3
or a larger but slower sceen in mode 4. The pixels of the Gameboy screen are
familiar to the bytesetting in mode 3, therefore I can set 4 bits in 1 copy-action.
This is my first trip with the new scheme. I had to rise earlier to catch my train.
After my cup of coffee it was again time to grap the laptop with SimCoupe on it.
I still had some altering in the intruptroutines to do. Somehow the intrupts were only called once.
I deleted the debugger for a while and added an intruptcounter. After the alterations I tested the program again.
Suddenly a flashing block kept appearing in the screen. Knowing that
the original game gives a flashing text from the start, this had to be the memory
that is filled by the program with the text. My screen is still pointing to a piece of RAM.
This piece must be used for the textdisplay. I checked the builtin intruptcounter: it raises!
I definitely must built the screenroutines now!
The routines are called by setting a bit and resetting this bit during the call.
After all intruptroutines are done all bits are reset. These bits must be set
again for the next intrupt. I think I just add a test on all reset and set them all again...
The return from intrupt didn't occur due to the combined EI / RETI
command in the source. RETI does an EI and a RET on the Gameboy.
So I combined both in one command. Forgetting to increase the PC after
a normal EI-command. Adding the increase made the RET go to the returnaddress+1.
Both are solved now, but after all intrupts (joypad/screen/timer etc.) the
program remains in DI-mode. I have to look at that now...
I coded intrupts last week, but the screen went bizar.
The A-register held a wrong value. It took me half an hour
to find it. Somehow the routine doesn't return from
intrupt. I will start the debugger when in intruptmode
Nice check for the way back home.
it ist time to go once again to Amsterdam.
I started the debugger and after a while I lost the debugger.
The emulator was cleaning the area I used for the debugger,
but after some adjustments I got it back.
The game in the ROM came in a waiting loop. It was waiting
for an intrupt from the vertical blanc counter.
So I added a counter during intrupt.
Then the game came in another waiting loop. It was truly
waiting for intrupts from the intruptroutine.
Seems like I must add intruptroutines now!
about the emulator. First I would like to say "Hi" to
the interested lady who sat beside me in the train to Boxmeer (she said she would take a look).
I got another half hour "quality time" from the dutch railroads,
which means I had another half hour delay on my trip,
but I used it to code the emulator.
I had started on the debugger and so now it was time
to test the emulation part. The debugger shows the
programcounter and all registers used. It waits for
the changing keypress of "1" or "2" before doing the
next opcode. I directly found a false emulated code.
I also found that the test for a ROM being used before
went wrong on the intruptroutine. The location of the
intruptroutine had changed (1 byte) in my program so
the call in the already altered ROM went wrong.
A simple solution to the problem was to ALWAYS set
the jump to the intruptserviceroutine in the emulator.
This weekend the dutch HCC-days are in Utrecht. I will
be at the HCC-Sinclair club on saturday, planning to
integrate the ZX-PC Interface with the SAM, so no
further coding until next week.
The aim is to make a debugger to check the emulation.
I need to switch from mode 4 to mode 1 to code a simple
singlestep debugger. After a traintrip of 1,5 hours
I have a debugger for singlestep checks and on paper
the rom which to test in assembler-code.
Checking starts at the way back home.
the translation table I was planned to use.
Although translation isn't planned yet, I already had
some thoughts about it. I planned to store the wrong code
in the table and find it back after a RST, determine
which code it is and jump to the altered routine.
Since it are just a few codes I plan to store the
low byte of the jumpvector. The high byte of all
jumpvectors will be constant so a jump to the altered
routine can be made faster.
a monochrome gameboy emulator.
A monochrome gameboy contains 4 'colors'
white, grey, dark grey and black.
I am still trying to find nice colorsettings for the emulation, but for now the equivalents are:
white, lightgreen, darkblue, black.
Whether these colors fit a nice screen will be seen later,
but I simply can alter the values for other colors.
I started the emulator after a game was loaded.
Since I need to capture an intrupt I had to alter a
piece of the ROM once on address #0038.
The code at this address is now stored on the memoryarea
containing the NINTENDO-logo. Also in this space 20
bytes are reserved to signal the fact that the ROM
is altered (in fact it's this message "SAM2_GB (c) 2006 YRS").
During intrupts F1 can now be pressed to return to BASIC.
The idea is to make a menu in BASIC to load games and
alter keysettings. But first emulationtests must be started.
on the SAM2_GB emulator. This emulator is the second in a
series of more (SAM2_ZX81, SAM2_GB, SAM2_P2000, SAM2_COVIS)
Whether all emulators can be made is still the question,
but the attempts will be made.
SAM2_ZX81 can be downloaded from WWW.WOMOTEAM.DE.
The workingconcept of the emulator
The gameboy holds a CPU almost equal to a Z80 processor.
The emulator must therefore emulate all opcodes to make it work in the right way.
Due to the emulation the programs will run slower than needed.
Therefore the emulator will determine which addresses use opcodes which are
not equal to their Z80-equivalent. The emulator will store the value in a table
and substitute the command with a RST which will handle the altered instruction.
The next time the emulator comes to this address it will run the code instead
of emulating and via the RST handles the altered commands in the right way.
Through this technic the game will eventually run on (almost) full speed.
Right now the emulator holds the emulation of all the opcodes.
A 32K game can be loaded and the test for correct emulation is planned...
