|
|
Post by VDC 8x2 on Apr 26, 2015 15:59:55 GMT
to translate it, I pretty much have to trace the program flow of the c64 version and translated it to vdc.
Hence, starting at the beginning and working my way to the end. aka load and credits.
|
|
|
|
Post by hydrophilic on Apr 27, 2015 4:33:57 GMT
Ahh... I was assuming the credits came at the end. That's what I get for assuming!
So yeah, that sounds like a plan... keep hacking away in your free time. I've enjoyed reading about everything so far...
Oh yeah, slightly related, I recently tried to open an old MS Access database... well not that old -- used it last year with my old PC (WinXP) for tracking business expenses.
When I had to do my taxes this year, I tried to open it on new PC (Win8... yuck). Well MS Access it needed to convert the database before it would open (I tried and failed to open the original)
So M!cro$oft did its conversion, but it failed... there were many many errors in the VB code used by database (well the GUI forms... the database itself can be updated with standard SQL)
Long story short, I eventually discovered that many BASIC functions that use to be 'standard' (like CHR$, LEFT$, MID$, LEN, etc.) are now sub-functions of the 'Strings' namespace... So I had to manually update all occurrences in my code (for example) from "Left(blah)" to "Strings.Left(blah)".
After doing that, it worked fine and I was able to file my taxes. Really strange that MS would fork the language like that, and more surprising they did not account for that in the 'upgrade' procedure. Pathetic, don't you think?
|
|
|
|
Post by VDC 8x2 on Apr 28, 2015 5:44:32 GMT
Fork them for forking that the forking forkers. lol
|
|
|
|
Post by hydrophilic on Apr 28, 2015 7:04:48 GMT
That is sooooo funny.  Thank you for the laugh... humor is the best medicine! |
|
|
|
Post by VDC 8x2 on May 16, 2015 20:34:55 GMT
I am banking in kernal to bank1 ram in a custom routine. It seems to lock up or go crazy when I call the kernal in a jsr. Is it a quirk or am I just going crazy?!?
|
|
|
|
Post by VDC 8x2 on May 17, 2015 13:59:22 GMT
Got the linker working! I had to rewrite the loading portion. I also had to put the game kernal into bank15.
So I am running the kernal in the $1c00 - $3fff area of bank 15 after doing a graphic 1,1 in the basic boot program. irq parts of the game will live in $1300 to $1bff of bank 15.
The linker and the rest of the code will live in bank1 with the i/o switched in. Calling game kernal through my custom farjsr routine in shared ram which is from $00 to $0fff. 4k instead of the normal 1k.
Global variables live in the shared ram area of $0b00 to $0fff
|
|
|
|
Post by hydrophilic on May 20, 2015 8:04:40 GMT
Cool... $1300 ~ $3fff (or in your version, $1c00~3fff) sitting in BANK 0 is a great way to implement common/kernel code on a C128 (note I said 'kernel' = your program core, as opposed to CBM 'KERNAL' = OS Core)
Trying to access BANK 1 can be tricky...
If you want to LOAD data (from a program running in Bank 0 or Bank 15), all you need is include JSR $FF68 (SetBank) before LOAD (JSR $FFD5)...
But if you want to execute code in BANK 1 that accesses the ROM/KERNAL, things are more complex!
In order to run code, which is stored in BANK 1, and calls the ROM/KERNAL (for example, LOAD), you have to implement a "custom" MMU configuration...
Sorry, but CBM never defined a "BANK (0~15)" which includes KERNAL ROM + Bank 1 RAM...
This means if you want to RUN code in Bank 1 RAM which has access to KERNAL ROM, you have to POKE the main MMU register ($ff00) with a "custom configuration"
From my programming experience, here are some of the most common (poke $ff00):
- $40 (decimal 64)- bank 1 RAM from $0000~$3fff, ROM/IO from $4000~FFFF (recommended)
- $7F (decimal 127) - all bank 1 RAM (not useful for your post, but may help others)
- $7E (decimal 126) - all bank 1 RAM except I/O registers are available ($d000~$dfff)
- $4E (decimal 78)- bank 1 RAM + KERNAL + I/O (ram $0000~bffff, rom_a $c000~cfff, I/O $d000~dfff, rom_b $e000~$ffff)
I think, based on your prior posts, that "custom" value of $4e would be best... RAM Bank 1 below $c000, yet KERNAL ROM and I/O from $c000~$ffff
Well that is what I think, feel free to flame me if I got it wrong! 
|
|
|
|
Post by VDC 8x2 on May 20, 2015 14:11:00 GMT
I think some of the CBM kernal was switching to bank15 on me with out me knowing. Therefore having the c128 in a bank I didn't want it in and casing the cpu jam with weird opcodes.
The code was solid and nolthing changed except moving it to bank 15 and adjusting for that.
At least that is my theory. I may be crazy...
|
|
|
|
Post by hydrophilic on May 26, 2015 5:54:01 GMT
Yeah, most KERNAL routines expect, and often force, BANK 15...
Often you can call KERNAL with some non-standard bank (some crazy MMU value) but it will execute/return from BANK 15...
Your idea to place all major (kernel) code at $1c00~3fff should work great with KERNAL...
Just be careful when a code in Bank 1 tries to call a KERNAL routine! (Might need a custom sub-routine to invoke BANK 15 before calling KERNAL plus a stub to restore Bank 1 before RTS)
I think/hope you know what I mean... but ask if you want details! |
|
|
|
Post by VDC 8x2 on May 26, 2015 21:08:38 GMT
yeah I am doing that my farjsr code:
/* Custom bank jsr
by vdc8x2
3/21/2015
lives in 4k shared ram
*/
.const MMUCR = $ff00
.const bank15 = %00000000
.const custbank1 = %01111110 //bank1 with i/o mapped in
//macros
.pseudocommand mov src;tar {
lda src
sta tar
}
.pc = $0AC6 "myjsrfar"
myjsrfar: { php
pha
:mov #bank15 ; MMUCR
pla
plp
.byte $20
.pc = * "jsraddress"
jsraddress: .word $ffff
php
pha
:mov #custbank1 ; MMUCR
pla
plp
rts
}
|
|
