Previous Thread
Next Thread
Print Thread
Page 2 of 3 1 2 3
Joined: May 2008
Posts: 68
Likes: 6
W
Walker Offline OP
Member
OP Offline
Member
W
Joined: May 2008
Posts: 68
Likes: 6
@golden child you're a saint laugh

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!

Joined: Nov 2004
Posts: 15
Likes: 3
S
Member
Offline
Member
S
Joined: Nov 2004
Posts: 15
Likes: 3
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
Joined: May 2008
Posts: 68
Likes: 6
W
Walker Offline OP
Member
OP Offline
Member
W
Joined: May 2008
Posts: 68
Likes: 6
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.

Joined: May 2008
Posts: 68
Likes: 6
W
Walker Offline OP
Member
OP Offline
Member
W
Joined: May 2008
Posts: 68
Likes: 6
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
Joined: Nov 2004
Posts: 15
Likes: 3
S
Member
Offline
Member
S
Joined: Nov 2004
Posts: 15
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.
Joined: May 2008
Posts: 68
Likes: 6
W
Walker Offline OP
Member
OP Offline
Member
W
Joined: May 2008
Posts: 68
Likes: 6
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 == x*2/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
Joined: May 2009
Posts: 2,188
Likes: 285
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 2,188
Likes: 285
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?

Joined: May 2008
Posts: 68
Likes: 6
W
Walker Offline OP
Member
OP Offline
Member
W
Joined: May 2008
Posts: 68
Likes: 6
I am sorry JD,

late at night etc wink

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?

Joined: May 2009
Posts: 2,188
Likes: 285
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 2,188
Likes: 285
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.

Joined: May 2008
Posts: 68
Likes: 6
W
Walker Offline OP
Member
OP Offline
Member
W
Joined: May 2008
Posts: 68
Likes: 6
Well I hoped for some low hanging fruits before I go deep into debugging hell

Page 2 of 3 1 2 3

Link Copied to Clipboard
Who's Online Now
0 members (), 49 guests, and 4 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,281
Posts121,425
Members5,064
Most Online1,283
Dec 21st, 2022
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Forum hosted by www.retrogamesformac.com