Home Page Forums MAME MAME some more commodore devices questions

Print Thread

Page 2 of 3

Re: some more commodore devices questions Walker #122074 03/13/23 09:12 PM
Joined: May 2008 Posts: 62 Likes: 4 Bremen W Walker OP Member
OP Walker Member W Joined: May 2008 Posts: 62 Likes: 4 Bremen	@golden child you're a saint my new testing code (after i played around with vice to compare what results i manage to get there, interestingly i get 4 extra bytes there, but that is not the point here) Code rem i set the baud rate to 1200 in the ui config with 8 bits, no parity,1 stop bit) OPEN5,2,1,CHR$(8):REM probably redundant but to be safe FORI=0TO12:PRINT#5,CHR$(I);:NEXT:PRINT#5 CLOSE5 let to the result i wanted to see (on c64p device) Code hexdump -C out64.txt 00000000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d \|..............\| 0000000e from this point on I can work out what i need to start debugging some stuff (i really want to see tape stuff working first, can't be a lot that is wrong) now checking 128d and with 1200 baud even in 128 mode this works equally well! Thanks a lot all of you!

Re: some more commodore devices questions Walker #122075 03/13/23 09:40 PM
Joined: Nov 2004 Posts: 13 Likes: 3 AU S sairuk Member
sairuk Member S Joined: Nov 2004 Posts: 13 Likes: 3 AU	Thanks for the code snippet, you'll need to match your baud rate etc under the Machine Configuration menu option (2400 baud below) `mame c128dp -w -user rs232 -user:rs232:rs232 null_modem -bitb outfile128.txt` c64p machine works ok Code hexdump -C outfile.txt 00000000 f8 f8 f8 00 00 00 f8 f8 f8 00 f8 00 f8 00 f8 f8 \|................\| 00000010 00 88 85 8c 8c 8f 0d 15 0d 48 45 4c 4c 4f 0d \|.........HELLO.\| 0000001f but yes, seems the 128 (in c64 mode as well) doesn't like it Code $ hexdump -C outfile128.txt 00000000 15 0d 88 85 8c 8c 8f 60 71 72 78 60 89 8e 60 83 \|.......`qrx`..`.\| 00000010 76 74 60 8d 8f 84 85 0d \|vt`.....\| 00000018 EDIT: ahh was updated as i was replying, great work. i'll have a play with your new snippet Last edited by sairuk; 03/13/23 09:41 PM. Reason: clarification
	1 member likes this: Walker

Re: some more commodore devices questions Walker #122076 03/13/23 10:05 PM
Joined: May 2008 Posts: 62 Likes: 4 Bremen W Walker OP Member
OP Walker Member W Joined: May 2008 Posts: 62 Likes: 4 Bremen	I grabbed those snippets togther from wherever I could find them, and while i do have a real 128d to test (but haven't set it up currently it is still boxed in and waiting for the sd card readers and a an 80 column monitor i still have to find) so i am sure that it is not supposed to work like that on the 128 (also haven't found the appropriate documentation for rs232 user port device programming yet). Also I don't have the real user port device - if I find one for a reasonable price I might test this then. By the way I also put this info into the wiki page as reference for whoever is interested in using this in the future.

Re: some more commodore devices questions Walker #122079 03/15/23 05:36 PM
Joined: May 2008 Posts: 62 Likes: 4 Bremen W Walker OP Member
OP Walker Member W Joined: May 2008 Posts: 62 Likes: 4 Bremen	just wanted to keep you guys updated. I searched for the documentation for the c64rs232 interface io programming - c64 creference programming chapter 06 Input Output Guide So one problem persists - the handling in MAME is definitely bugged: my test snippet (ran it in both mame and vice) test output loop 1200 baud 8 bit no parity 1 stop bit Code OPEN5,2,0,chr$(8) FORI=0TO255:print#5,CHR$(I);:NEXT CLOSE5 output received in MAME: Code hexdump -C out128_reworked.txt 00000000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f \|................\| 00000010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f \|................\| 00000020 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f \|`abcdefghijklmno\| 00000030 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f \|pqrstuvwxyz{\|}~.\| 00000040 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f \|................\| 00000050 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f \|................\| 00000060 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef \|................\| 00000070 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff \|................\| 00000080 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f \|................\| 00000090 10 11 12 13 14 ff 15 16 17 18 19 1a 1b 1c 1d 1e \|................\| 000000a0 1f 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e \|.`abcdefghijklmn\| 000000b0 6f 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e \|opqrstuvwxyz{\|}~\| 000000c0 7f 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e \|................\| 000000d0 8f 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e \|................\| 000000e0 9f e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee \|................\| 000000f0 ef f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe \|................\| 00000100 ff \|.\| output received in vice: Code hexdump -C testc128_loop256.out 00000000 c9 e2 86 d5 ff 00 ff 01 00 01 02 03 04 05 06 07 \|................\| 00000010 00 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 \|................\| 00000020 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 \|........ !"#$%&'\| 00000030 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 \|()+,-./01234567\| 00000040 38 39 3a 3b 3c 3d 3e 00 40 41 42 43 44 45 46 47 \|89:;<=>.@ABCDEFG\| 00000050 48 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57 \|HIJKLMNOPQRSTUVW\| 00000060 58 59 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 67 \|XYZ[\]^_`abcdefg\| 00000070 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 \|hijklmnopqrstuvw\| 00000080 78 79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 \|xyz{\|}~.........\| 00000090 88 89 8a 8b 8c 8d 8e 8f 90 91 92 93 94 95 96 97 \|................\| 000000a0 98 99 9a 9b 9c 9d 9e 9f a0 a1 a2 a3 a4 a5 a6 a7 \|................\| 000000b0 a8 a9 aa ab ac ad ae af b0 b1 b2 b3 b4 b5 b6 b7 \|................\| 000000c0 b8 b9 ba bb bc bd be bf c0 c1 c2 c3 c4 c5 c6 c7 \|................\| 000000d0 c8 c9 ca cb cc cd ce cf d0 d1 d2 d3 d4 d5 d6 d7 \|................\| 000000e0 d8 d9 da db dc dd de df e0 e1 e2 e3 e4 e5 e6 e7 \|................\| 000000f0 e8 e9 ea eb ec ed ee ef f0 f1 f2 f3 f4 f5 f6 f7 \|................\| 00000100 f8 f9 fa fb fc fd fe ff ff \|.........\| so since I don't have the real hardware interface to compare at the moment, I have to trust that the output in vice can be trusted as correct - despite the fact that there are additional bytes at the start where I do not know their meaning (not sure if a vice expert lurks around here and could throw in some wisdom about this?). I also tried to follow the reference manual which suggests testing the ST Status value (Input Output Guide Page 354) - but in mame this value does not return anything meaningful and the status check loop runs infinitely. (same in vice) I also tried to go down to 300 baud, but the results won't become better. PS: results above are with c128dp device in MAME and c128 in vice the c64p device gives correct values for the listed basic code: Code hexdump -C out64_reworked.txt 00000000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f \|................\| 00000010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f \|................\| 00000020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f \| !"#$%&'()+,-./\| 00000030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f \|0123456789:;<=>?\| 00000040 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f \|@ABCDEFGHIJKLMNO\| 00000050 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f \|PQRSTUVWXYZ[\]^_\| 00000060 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f \|`abcdefghijklmno\| 00000070 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f \|pqrstuvwxyz{\|}~.\| 00000080 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f \|................\| 00000090 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f \|................\| 000000a0 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af \|................\| 000000b0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf \|................\| 000000c0 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf \|................\| 000000d0 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df \|................\| 000000e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef \|................\| 000000f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff \|................\| I will try to find some documentation for c128 Input Output in case there are differences, but since the values in vice look ok, I do believe that there is something going wrong inside the MAME device. PSPS: to make things even more fun my above results are for the PAL Device, I just had the flashy idea to compare with the NTSC Device ét voilá, that one has correct output: Code hexdump -C out128_ntsc.txt 00000000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f \|................\| 00000010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f \|................\| 00000020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f \| !"#$%&'()*+,-./\| 00000030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f \|0123456789:;<=>?\| 00000040 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f \|@ABCDEFGHIJKLMNO\| 00000050 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f \|PQRSTUVWXYZ[\]^_\| 00000060 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f \|`abcdefghijklmno\| 00000070 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f \|pqrstuvwxyz{\|}~.\| 00000080 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f \|................\| 00000090 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f \|................\| 000000a0 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af \|................\| 000000b0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf \|................\| 000000c0 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf \|................\| 000000d0 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df \|................\| 000000e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef \|................\| 000000f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff \|................\| My best guess - the main problem is obviously in the PAL Timing values? Last edited by Walker; 03/15/23 06:17 PM.
	1 member likes this: sairuk

Re: some more commodore devices questions

Walker #122080 03/15/23 09:28 PM

Joined: Nov 2004

Posts: 13

Likes: 3

sairuk

Member

sairuk

Member

Joined: Nov 2004

Posts: 13

Likes: 3

arguably as expected but for completeness, using walkers snippet

c128dp in c64 mode also exhibits the same behaviour

Code

$ hexdump -C outfile128dp.txt 
00000000  00 01 02 03 04 05 06 07  08 09 0a 0b 0c 0d 0e 0f  |................|
00000010  10 11 12 13 14 15 16 17  18 19 1a 1b 1c 1d 1e 1f  |................|
00000020  60 61 62 63 64 65 66 67  68 69 6a 6b 6c 6d 6e 6f  |`abcdefghijklmno|
00000030  70 71 72 73 74 75 76 77  78 79 7a 7b 7c 7d 7e 7f  |pqrstuvwxyz{|}~.|
00000040  80 81 82 83 84 85 86 87  88 89 8a 8b 8c 8d 8e 8f  |................|
00000050  90 91 92 93 94 95 96 97  98 99 9a 9b 9c 9d 9e 9f  |................|
00000060  e0 e1 e2 e3 e4 e5 e6 e7  e8 e9 ea eb ec ed ee ef  |................|
00000070  f0 f1 f2 f3 f4 f5 f6 f7  f8 f9 fa fb fc fd fe ff  |................|
00000080  00 01 02 03 04 05 06 07  08 09 0a 0b 0c 0d 0e 0f  |................|
00000090  10 11 12 13 14 15 16 17  18 19 1a 1b 1c 1d 1e 1f  |................|
000000a0  60 61 62 63 64 65 66 67  68 69 6a 6b 6c 6d 6e 6f  |`abcdefghijklmno|
000000b0  70 71 72 73 74 75 76 77  78 79 7a 7b 7c 7d 7e 7f  |pqrstuvwxyz{|}~.|
000000c0  80 81 82 83 84 85 86 87  88 89 8a 8b 8c 8d 8e 8f  |................|
000000d0  90 91 92 93 94 95 96 97  98 99 9a 9b 9c 9d 9e 9f  |................|
000000e0  e0 e1 e2 e3 e4 e5 e6 e7  e8 e9 ea eb ec ed ee ef  |................|
000000f0  f0 f1 f2 f3 f4 f5 f6 f7  f8 f9 fa fb fc fd fe ff  |................|
00000100

c128 in c64 mode is ok

Code

$ hexdump -C outfile128.txt 
00000000  00 01 02 03 04 05 06 07  08 09 0a 0b 0c 0d 0e 0f  |................|
00000010  10 11 12 13 14 15 16 17  18 19 1a 1b 1c 1d 1e 1f  |................|
00000020  20 21 22 23 24 25 26 27  28 29 2a 2b 2c 2d 2e 2f  | !"#$%&'()*+,-./|
00000030  30 31 32 33 34 35 36 37  38 39 3a 3b 3c 3d 3e 3f  |0123456789:;<=>?|
00000040  40 41 42 43 44 45 46 47  48 49 4a 4b 4c 4d 4e 4f  |@ABCDEFGHIJKLMNO|
00000050  50 51 52 53 54 55 56 57  58 59 5a 5b 5c 5d 5e 5f  |PQRSTUVWXYZ[\]^_|
00000060  60 61 62 63 64 65 66 67  68 69 6a 6b 6c 6d 6e 6f  |`abcdefghijklmno|
00000070  70 71 72 73 74 75 76 77  78 79 7a 7b 7c 7d 7e 7f  |pqrstuvwxyz{|}~.|
00000080  80 81 82 83 84 85 86 87  88 89 8a 8b 8c 8d 8e 8f  |................|
00000090  90 91 92 93 94 95 96 97  98 99 9a 9b 9c 9d 9e 9f  |................|
000000a0  a0 a1 a2 a3 a4 a5 a6 a7  a8 a9 aa ab ac ad ae af  |................|
000000b0  b0 b1 b2 b3 b4 b5 b6 b7  b8 b9 ba bb bc bd be bf  |................|
000000c0  c0 c1 c2 c3 c4 c5 c6 c7  c8 c9 ca cb cc cd ce cf  |................|
000000d0  d0 d1 d2 d3 d4 d5 d6 d7  d8 d9 da db dc dd de df  |................|
000000e0  e0 e1 e2 e3 e4 e5 e6 e7  e8 e9 ea eb ec ed ee ef  |................|
000000f0  f0 f1 f2 f3 f4 f5 f6 f7  f8 f9 fa fb fc fd fe ff  |................|
00000100

Last edited by sairuk; 03/15/23 09:29 PM.

Re: some more commodore devices questions Walker #122083 03/18/23 01:57 AM
Joined: May 2008 Posts: 62 Likes: 4 Bremen W Walker OP Member
OP Walker Member W Joined: May 2008 Posts: 62 Likes: 4 Bremen	I am digging through the MAME Source and have a question. I compared the c64 and the c128 initialisation (PAL) and wondered about the different quartz values XTAC( init values in c128.cpp line 1829 Z80(config, m_maincpu, XTAL(17'734'472)2/4.5/2); line 1833 M8502(config, m_subcpu, XTAL(17'734'472)2/4.5/8); ^^ this i can see in c64.cpp line 1799 x/18 == x2/4.5/8 line 1848 MOS8563(config, m_vdc, XTAL(16'000'000)); but why 16.000.000? this is the 80 column screen driver freq and thus the same on ntsc and pal? line 1860 mos8566_device &mos8566(MOS8566(config, MOS8566_TAG, XTAL(17'734'472)2/4.5)); ^^ double freq, mkay its a 128? or is there another /2 missing? line 1878 MOS6581(config, m_sid, XTAL(17'734'472)2/4.5/8); line 1884 MOS8722(config, m_mmu, XTAL(17'734'472)2/4.5/8); line 1893 MOS6526(config, m_cia1, XTAL(17'734'472)2/4.5/8); line 1903 MOS6526(config, m_cia2, XTAL(17'734'472)2/4.5/8); ^^ this one is connected to tape, but the problem must be deeper there since it exists both on pal and on ntsc edit1: had some mixup with the ntsc startup at first, sadly in the pal init these values correspond to the c64 pal init values as far as i can see - it would have been too easy else... edit2: since i own a 128dcrp now, i guess that i should be able to find the quartz' with these values on the board - should i see it multiple times, and with the exact value or do i need some hardware to be able to determine the correct frequencies? or can it be sourced from a single quartz so i should only see one 16.000.000 and one 17.734.472 hz quartz? Last edited by Walker; 03/18/23 02:38 AM. Reason: assumptions i should test by compiling myself

Re: some more commodore devices questions Walker #122084 03/18/23 09:34 AM
Joined: May 2009 Posts: 2,120 Likes: 152 J Just Desserts Very Senior Member
Just Desserts Very Senior Member J Joined: May 2009 Posts: 2,120 Likes: 152	It's really difficult to understand your latest post. You're shotgunning a bunch of individual lines (also without bookending them in code-block specifiers, so they're appearing in proportional fonts rather than monospaced), and your list of edits is equally hard to follow since it's rather stream-of-consciousness. Would you mind replying with a concise description of what your question actually is?

Re: some more commodore devices questions Just Desserts #122085 03/18/23 10:44 AM
Joined: May 2008 Posts: 62 Likes: 4 Bremen W Walker OP Member
OP Walker Member W Joined: May 2008 Posts: 62 Likes: 4 Bremen	I am sorry JD, late at night etc Since one of the problems I see in the c128 core at the moment (PAL bug with rs232 interface vs NTSC which runs correctly) I was trying to make some sense out of the MAME driver source. At first I thought I would see some wrong values in the XTAC calls, but that one was mostly erronously mixing up the ntsc and pal init source by myself. Question 1: Except for line 1860 - I do not understand why mos8566_device &mos8566(MOS8566(config, MOS8566_TAG, XTAL(17'734'472)2/4.5)); is used as init value. I would have thought that mos8566_device &mos8566(MOS8566(config, MOS8566_TAG, XTAL(17'734'472)2/4.5/8)); should have been there - but very probably I am missing something in my understanding here - since the ntsc part has a similar configured ntsc value there in line 1681: MOS8564(config, m_vic, XTAL(14'318'181)*2/3.5);? Since the tape does not work for both versions - is it possible that this one is the culprit for the problem "not being able to load any softwarelist tape" ? Question 2: Since I am not really a hardware guy I would like to know if I can see the very same quartz values on the real board - I have a c128dcrp system around and could compare what is there in case it uses a slightly different quartz?

Re: some more commodore devices questions Walker #122086 03/18/23 11:33 AM
Joined: May 2009 Posts: 2,120 Likes: 152 J Just Desserts Very Senior Member
Just Desserts Very Senior Member J Joined: May 2009 Posts: 2,120 Likes: 152	I think the best possible thing to do in this case is to take nothing for granted, and just work backward from the problem itself. If the system can't load software from tape, then start debugging it from that standpoint. Make no assumptions about the correctness or incorrectness of anything. As for the crystal values on a real board, maybe? But it sounds like you're "putting the cart before the horse", so to say. Focus less on the crystal values and more on tape loading not working. Just debug it from a vacuum. If it turns out that it's a clocking issue, then you'll find that out as part of the debugging process. But if you over-focus on a particular thing, you might end up leading yourself down a fruitless path.

Re: some more commodore devices questions Walker #122087 03/18/23 03:38 PM
Joined: May 2008 Posts: 62 Likes: 4 Bremen W Walker OP Member
OP Walker Member W Joined: May 2008 Posts: 62 Likes: 4 Bremen	Well I hoped for some low hanging fruits before I go deep into debugging hell

Page 2 of 3

Moderated by Bletch, R. Belmont, Richard Bannister

Link Copied to Clipboard