|
Post by mirkosoft on Jul 11, 2016 7:51:38 GMT
Hi! I created few EPROM images for Commodore 128 internal or external ROM for using in VICE - it's very easy and like is in Commodore 128 Memory Management manual written there is also how to create cartridges for C64. I tried to attach C64 cartridge created by that manual to VICE64, but I found only Generic Games cartridges - no generic standard cartridges - and more specified cartridges. When I was on the end with C64 knowledge, I found over the web CRT image structure, but each time it failed, like generic game cartridges... I VICE is option for generic cartridges only game or MAX machine, so it looks like C64 is only game and music console. Can anybody please explain me how to create cartridge working in X64 of VICE? Thank you for all. Miro 50
|
|
|
Post by Eslapion on Jul 18, 2016 22:20:29 GMT
There exist a number of specific structures for CRT files. Do you already know the structure you would like your image to use ? The possible cartridge types supported by CRT files are listed here: ar.c64.org/wiki/CRT_ID
|
|
|
Post by mirkosoft on Jul 18, 2016 22:43:44 GMT
Thak you for link. I tried VICE's CARTCONV, but cartridge created by manual written in pevous post hangs x64, conversion to CRT was succesfull, but see no ID problem, so there is anything other... now I'm busy, later attach source.
Miro
|
|
|
Post by Eslapion on Jul 19, 2016 0:46:53 GMT
Thak you for link. I tried VICE's CARTCONV, but cartridge created by manual written in pevous post hangs x64, conversion to CRT was succesfull, but see no ID problem, so there is anything other... now I'm busy, later attach source. Miro I suppose it's a lot easier to take a CRT file already prepared and only replace the content of the ROM files. For example, if you want a custom Fastload CRT then just take the CRT file for the real Fastload cart and change the content of the ROM image (noted CHIP in the CRT file hex: 43 48 49 50 ) Then use the following structure: example: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ASCII ----------------------------------------------- ---------------- 0000: 43 48 49 50 00 00 20 10 00 00 00 00 80 00 20 00 CHIPúúúúúúúú€úúú Bytes:$0000-0003 - Contained ROM signature "CHIP" (note there can be more than one image in a .CRT file) 0004-0007 - Total packet length ($00002010, ROM image size and header combined) (high/low format) 0008-0009 - Chip type 0 - ROM 1 - RAM, no ROM data 2 - Flash ROM 000A-000B - Bank number ($0000 - normal cartridge) 000C-000D - Starting load address (high/low format) 000E-000F - ROM image size in bytes (high/low format, typically $2000 or $4000) 0010-xxxx - ROM data I assume it's much easier to modify and existing CRT file than to create one from scratch.
|
|
|
Post by eslapion on Jul 23, 2016 6:56:19 GMT
mirkosoftI sifted through my cartridge files stuff today and found a pair of CRT files that LordCrass created for me about 3 years ago. I love the cartridge version of Super Zaxxon but the officially available version of the CRT file will not work with EasyFlash 3; LordCrass actually converted the CRT file into a different format which works on EF3. As I discovered today, the new CRT file format which is double the size of the original CRT also works with the 1541 Ultimate I/II !! Thanks again LordCrass!!
|
|
|
Post by mirkosoft on Jul 23, 2016 15:48:57 GMT
I tried to get help on Forum64 - it's C64 forum. They give me advices that C128 handles cartridges totally different way like C64 and they told that what is written in C128 Memory Management is for C64 unusable. I got this these 2 links:
codebase64.org/doku.php?id=base:assembling_your_own_cart_rom_image www.sd2iec.de/
I was following Codebase and get x64 to accept catridge as CRT and also Generic 8K (both files) All was looking ok, but x64 after attaching cartridge performs reset and hangs, next or more resets hangs few second and then execute code, but at RTS performs NMI (like STOP+RESTORE)... Then I was not testing it more and no more help on Forum64 'cause I wrote cartridge purpose - direct execute Z80 code from Basic (Z80 in CP/M cartridge). First were words that it's not possible to have to C64 connected 2 cartridges - CP/M and my custom, that's truth on real hardware (of course X-Pander-3 etc. it makes possible). VICE's x64 allows to have enabled CP/M cartridge and attached own CRT or BIN too.
Now it's in topic on Forum64 talking about Z80 and CP/M etc. Also warning me that it's not possible... I own C128DCR, SuperCPU128 and CP/M cartridge and know what it can and what cannot. In discussion I wrote words about calling external Z80 by internal Z80 - it's possible - I know not to handle it for now. Why? When I switch Z80 to Z80 it performs not stop internal Z80, it performs stop 8502 - so running both Z80 at once? Two working CPUs in C128 is not possible for its design, When is called internal Z80 it stops 8502 and vice versa. CP/M cartridge is designed that when is calling external Z80 it stops 8502 and vice versa, but when is calling external Z80 from internal Z80, it performs stop 8502 and internal Z80 has no signal to end processing... so this I want to discover, maybe you friends can help me - C128 was not designed to calling Z80 to Z80 - it sends not signal to stop one of them...
But again to cartridge, here's source code which is created by following Codebase:
*=$8000
.byte $09, $80 ; Cold start vector .byte $25, $80 ; Warm start vector .byte $C3, $C2, $CD, $38, $30 ; "CBM80"
; Kernal reset routine stx $d016 ; turn on VIC for PAL / NTSC check jsr $fda3 ; IOINIT - init CIA chips jsr $fd50 ; RANTAM - clear/test system RAM jsr $fd15 ; RESTOR - init Kernal RAM vectors jsr $ff5b ; CINT - init VIC and screen editor cli ; re-enable IRQ interrupts
; Nasic reset routine
jsr $e453 ; init Basic RAM vectors jsr $e3bf ; main Basic RAM init routine jsr $e422 ; power-on message / new command ldx #$fb txs ; reduce stack pointer for Basic
; START YOUR PROGRAM HERE ($8025)
start: lda #4 ; purple sta $d020 ; border lda #5 ; white ink jsr $ffd2 ; BSOUT rts
*=$9c40 ; SYS40000,lo,hi
z8064: sta lo ; store LO-byte for Z80 routine call txa sec sbc #$10 ; convert HI byte to Z8064 addressing sta hi ; store HI-byte for Z80 routine call ldx #00 loop: lda z8064start,x sta $1000,x ; copy Z8064 start routine to x65 $1000 / x80 $0000 inx cmp #$ff bne loop lda lo ldx hi sta $1002 ; place LO-byte to copied Z8064 code stx $1003 ; place HI-byte to copied Z8064 code lda 53432 ; get current SCPU speed sta speed lda #00 ; slow down sta 53370 ; to 1MHz lda #00 ; switch sta $de00 ; to Z80 nop lda speed cmp #1 bne exit lda #00 ; speed up sta 53371 ; to 20MHz exit: rts
speed: .byte 0 lo: .byte 0 hi: .byte 0
z8064start: .byte $00, $cd, $00, $00, $3e, $01, $32, $00, $ce, $00, $c3, $00, $00, $ff
;Z8064CALL ; CALL $0000 ; JSR subroutine ; LD A, $01 ; switch to ; LD ($ce00),A ; switch to X65K ; NOP ; JP $0000 ; after CPU switch pointer is here, so jump to execute subroutine again
*=$9fff ; 8K Cartridge
.byte 0
Thank you for advices to solve hanging and you friends - write if I have to start topic aout C128 and two Z80 - DualCore Z128 :)
Miro
|
|
|
Post by eslapion on Jul 23, 2016 17:31:16 GMT
I you find out how to turn the C128 into a dual processor machine, that would be an amazing feat.
|
|
|
Post by mirkosoft on Jul 27, 2016 0:05:49 GMT
OK, first results.
Tested were both Z80 separately and in both C128 modes - 128 and 64. Long time known thing is that calling missing Z80 never produces crash, for example - internal Z80 is not accessible while is SCPU turned on or in 64 mode. The same is for external Z80 - if is not present, code continues normally without crash.
I created two separate routines for each Z80 - internal increment VIC border, external increment VIC paper. I tried them in all possible combinations with SCPU, CP/M cartridge, 64 mode etc. - all was working correctly.
Then I started Dual Z80 routine. Yesterday routine starts and hanging computer. This was surprise 'cause before using handling code after switch from internal Z80 to external Z80 it always crashed. It was looking like code attempts to switch and continue, but hanging is not ok. This night I tried similar code. Routine starts in 8502 code to switch to internal Z80, then internal Z80 attempts switch to external Z80 and then continues with border increment. So, I was waiting for starting increment VIC paper by external Z80 and by internal Z80 increment VIC border at once. It works not - looks like switch to external Z80 is not succesfull. Ok, this can be waited, but why happened problems before? I was searching in resources and found that expansion port pin 7 allows to activate external Z80, there is CP/M cartridge connected and this is reason why can work with SCPU too. Running with SCPU requires only slow down to 1MHz while running Z80 code, only for switch sync. Internal Z80 is not possible to access with SCPU for hardware connection and in 64 mode disabling MMU. But here's Q - expansion port, especially pin 7, is maybe accessible by internal Z80, why to throw out hardware which can run with Z80... If is accessible it needs to find where and then switch it by that way. This switch produces signal to 8502 (or 6502) to turn off, but it was not designed to produce signal to turn off internal Z80 - so this fight I lost not yet. Many times is easy to find CP/M memory map - for your info - C128's CP/M3 handles whole 128K - many times I had to read that 64K only. And finding differences between CP/M memory map and 8502 memory map is not true for Z80 between 8502 - CP/M is operating system, example: CP/M uses for 40 column screen attributes area $1000-$1300 etc., but if you want to POKE by Z80 code any character to 40 column screen you must to use area $0400-$07E7 (by default). So comparing CP/M and 8502 memory maps is mismatch. It needs to compare Z80 between 8502 map. And differently is RAM mapped by internal and external Z80 - internal uses same addressing, but external Z80 has whole RAM shifted $1000 lower - and accessing switch there is $CE00 instead 8502/internal Z80 $DE00 - so external Z80 see pin 7, again reason why to search... Here it looks like no source to get where is mapped exp. port - or I can to use also not IO opcodes and try it again. Also 64 mode has not accessible MMU and other differences can make it not accessible, but CP/M cartridge I was using first time with C128 - I was warned that it's impossible to use and my results were succesfull and rewritten words in one SuperCPU FAQ page... Very important is in Z80 assembler to use correct opcodes - for IO IN and OUT and normally LD... I will experiment - this fight is not finished, not yet has winner.
If anyone has any knowledge in mapping C128's RAM and exp. port for Z80, suggestions and each help are welcome. Please don't forgive that this topic was started for help with C64 cartridge. So, thank you all.
Miro
|
|
|
Post by mirkosoft on Jul 30, 2016 15:59:08 GMT
In all, no matter if is exp.port accessible, when could be both Z80 running at once, it could only make fight to data bus and memory - for access priority are not designed. ZX Spectrum has contended memory where is used access priority between CPU and ULA. Both cannot access this part memory at once. If could have C128 similar priority for access, two Z80 running at once could be possible - but C128 is not designed for... Also - thanks to Forum64 users which helped me with cartridge, but it's not working for now, and also Z80 discovering.
Miro
|
|
|
Post by remark on Aug 3, 2016 13:05:43 GMT
Miro,
I think this happens: the internal Z80 runs in the PhiLo phase (VIC IIe-cycle), the external Z80 runs in the PhiHi phase (8502-cycle). The external Z80 releases the bus in PhiLo, because it needs VIC-IIe to function. The internal Z80 will start to run again, but because the adress-/databus is not valid for internal Z80 (external Z80 changed that) there will be a crash.
Switching off VIC-IIe will not change that, because external Z80 will always release bus in PhiLo (cartridge was designed that way, in C64 PhiLo is always VIC-II-cycle)
Switching from 8502 to external Z80 will work, because PhiLo is always VIC-IIe cycle.
|
|