kl99

I was able to identify all 23 line numbers, they are stored as hexadecimal words, so two byte each.

>E970: Yellow is the string segment, however they get auto-splitted and in reverse order written in memory. Orange is the length of the whole string segments (that is splitted) Blue is the variable name. if more than length of 1 a FF is used to finalize the entry it seems. Orange is alsof ro the length of numeric variable definitions

it looks like the area of the onchip CPU Ram is highly used. so Michael, can you help me relocated the POKEs to another location? It crashes already when executing only the 3 lines of POKEs and then trying to peek if those have been written correct. So it crashes without the MCHL. It looks like either the Hex-Bus RS232 DSR or the 99/2 Hex Bus DSR (don't know the details) is using E000 for some RS232 buffer. At least the Hex-Dump indicates this. So I would suggest E100 or even EC00 (Screen Location). E000: >00 00 40 00 80 14 00 01 .... E020: >30 30 30 30 34 30 30 30 38 30 31 34 30 30 30 31 = "00 00 40 00 80 14 00 01" [byte format]

"HEXBUS.20.B=9600.D=7.S=1.P=E"

okay. it got stuck twice in a row. i changed the rs232 config a bit, i hope it is better with Parity enabled. At least now it worked . 50 REM INITIAL COMMENT TO IDENTIFY PROGRAM SPACE 60 REM "SECOND COMMENT WITHIN DOUBLE QUOTES" 70 PRINT "WE CAN START THE DUMP OF THE RAM" 100 OPEN #1:"HEXBUS.20.B=9600.D=7.S=1.P=E",OUTPUT 110 FOR I=-8192 TO -3845 120 CALL PEEK(I,P) 130 H1=INT(P/16) 140 H2=P-H1*16 150 IF H1>9 THEN 180 160 H1$=CHR$(48+H1) 170 GOTO 190 180 H1$=CHR$(87+H1) 185 REM MIZAPF FIND THIS LINE 190 IF H2>9 THEN 220 200 H2$=CHR$(48+H2) 210 GOTO 230 220 H2$=CHR$(87+H2) 230 PRINT #1:H1$;H2$; 240 PRINT H1$;H2$; 250 NEXT I 260 CLOSE #1 270 PRINT "THIS IS ALL FOLKS GOOD BYE" 280 REM END OF PROGRAM e000-rem-sorted.bas e000-rem-sorted.bin e000-rem-sorted-ver2-incomplete.bin I expanded the dumping area to include the 252 bytes of the cpu ram at F000. i did enter the lines in correct order and did start from a fresh turn on of the machine, with no other commands in advance or before entering RUN. no editing of errors had to be done. so the ram should be as virgin as possible. LIST "HEXBUS" of the source program was performed after the dump completed. Running it currently a second time directly after LIST command. If successful I will attach the second dump as well. EDIT: 2nd dump got stuck again, but the area til EC00 is all in there. Therefore attached.

back on the 99/2. rs232 transfer got stuck on pc side again. arrgh restart

0000-1FFF ROM Bank #1...........8192 Bytes 2000-3FFF ROM Bank #2...........8192 Bytes 4000-5FFF ROM Bank #3...........8192 Bytes 6000-7FFF write protected.......8192 Bytes 8000-9FFF write protected.......8192 Bytes A000-BFFF write protected.......8192 Bytes C000-DFFF write protected.......8192 Bytes E000-EBFF RAM...................3072 Bytes EC00-EEFF RAM VDP Address Table..768 Bytes EF00-EFFF RAM................... 256 Bytes F000-F099 RAM................... 154 Bytes F09A-F09B write protected..........2 Bytes F09C-F09D RAM......................2 Bytes F09E-F0A1 write protected..........4 Bytes F0A2-F0AB RAM.....................10 Bytes F0AC-F0BB write protected.........16 Bytes F0BC-F0BD RAM......................2 Bytes F0BE-F0C5 write protected..........8 Bytes (F0C6-F0E3 poking crashes/breaks...30 Bytes) F0CE-F0D1 write protected..........4 Bytes F0D2 breaks F0D3 RAM F0D4 breaks F0D5 RAM F0D6-F0D9 write protected.......... F0DA-F0E1 RAM F0E2 RAM (screwed up output) F0E3 RAM (screwed up output) F0E4-F0FB RAM.....................24 Bytes F0FC-FFF9 write protected.......3838 Bytes FFFA-FFFF RAM......................6 Bytes enough for today. will continue tomorrow...

okay. verified now that poking does not change any byte from 0000-DFFF. that was expected but it is nice to be confirmed now. next is the not writable parts where we expect RAM to be.

ok. back at the 99/2 now

Preliminary Memory Map, based on findings: 0000-1FFF ROM Bank #1...........8192 Bytes 2000-3FFF ROM Bank #2...........8192 Bytes 4000-5FFF ROM Bank #3...........8192 Bytes 6000-7FFF not writable area.....8192 Bytes 8000-9FFF not writable area.....8192 Bytes A000-BFFF not writable area.....8192 Bytes C000-DFFF not writable area.....8192 Bytes E000-EBFF RAM...................3072 Bytes EC00-EEFF RAM VDP Address Table..768 Bytes EF00-EFFF RAM................... 256 Bytes F000-F099 RAM................... 154 Bytes F09A-F0A1 not writable area........8 Bytes F0A2-F0AB RAM.....................10 Bytes F0AC-F0C5 not writable area.......26 Bytes F0C6-F0E3 poking crashes/breaks...30 Bytes F0E4-F0FB RAM.....................24 Bytes F0FC-FFF9 not writable area.....3838 Bytes FFFA-FFFF RAM......................6 Bytes The 'not writable area's could be false flags still. I poked a value to each memory location and if the poked value could not be peeked afterwards, I assumed it is not writable. However this leaves out the usecase where the system updated the memory location before I was able to peek again. So next I will check if the last peek matches the initial peek and only then assume it is not writable.

The rs232 peeking got stuck twice on PC side when dumping RAM E000-EFFF. It has frozen the com port til next windows restart. So I have reduced the baudrate to 2400. It went through this time. Attached you will find the program that was in the memory when dumping e000-efff. e000-efff-prg-in-memory.bas It got transfered via LIST "HEXBUS.xxx..." The dump output is this e000-efff.bin e000-efff-dump2.bin I am running it three times, so we can see differences that got updated by buffer content, changed basic system variables etc. Okay, only two time. 99/2 crashed during third run. The Machine feels a bit hot. I will turn it off for a while. Both dumps are attached. They contain the basic program in memory. At least part of it for sure.

now i am dumping the content of the RAM via RS232 to look inside without changing the video memory content.

-8192 to 7169 is RAM [E000-E3FF] -7168 to -6145 is RAM [E400-E7FF] -6144 to -6143 is RAM [E800- -4096 to -3943 is RAM -3942 to -3935 is not writable -3934 to -3925 is RAM -3924 to -3899 is not writable .. poking can be crashing here... -3869 poking is screwing up the output -3868 to -3845 is RAM -3844 to -7 is not writable -6 to -1 is RAM -5120 is the first character of Video Screen [EC00] -4353 is the last character of Video Screen [EEFF]

24576 to 28671 is not available as RAM [6000-6FFF] 28672 to 32767 is not available as RAM [7000-7FFF] -32768 to -28673 is not available as RAM [8000-8FFF] -28672 to -24577 is not available as RAM [9000-9FFF] -24576 to -20481 is not available as RAM [A000-AFFF] -20480 to -16385 is not available as RAM [b000-BFFF] -16384 to -12289 is not available as RAM [C000-CFFF] -12288 to -8193 is not available as RAM [D000-DFFF]

-8192 to -7169 is RAM [E000-E3FF] -7168 to -6145 is RAM: but poking -6271 or the next (-6270) caused a string number mismatch. so we must have screwed up system variables of basic/monitor/vdp or entered the program storage area. -32768 to -28673 is not available as RAM [8000-8FFF] -28672 to -24577 is not available as RAM [9000-9FFF] -24576 to -20481 is not available as RAM [A000-AFFF] -20480 to -16385 is not available as RAM [b000-BFFF] -16384 to -12289 is not available as RAM [C000-CFFF] -12288 to -8193 is not available as RAM [D000-DFFF]

Hi Michael and everyone else! I was finally able to setup another dump program that is using Hex-Bus RS232 to transmit each bytes as two hexadecimals over the serial port. The bank0 got dumped and is matching exactly the binary of the former dump from my machine. When adding the 4 lines however it did nothing when RUN the first time and crashed on the second time. It is already late in Vienna. I will verify the address range of the RAM by doing some PEEKs and POKEs to see if the POKEd value can be PEEKed afterwards. Tomorrow we will get this together done hopefully. Other than adding the 4 lines by mizapf the Line 110 got changed to 110 FOR I=-4224 TO -4209

the ugly photocopy manual of the Tombstone City is really something I am still missing, haha

And when going through that 99/2 manuals, I imagined the cassettte recorder SAVE option

i reinstalled the original drive in the HX-5102, same I/O error 02 results. When talking today with Jens-Eike we figured that I might constantly enter the save command wrong. when he asked me whether the SAVE "DSK1.T" works, seeing those doublequotes made me think. i am not infront of the unit now but I think i always entered it like External Disk Drive connected to the HX-5102 SAVE "HEXBUS.102.T" Internal Disk Drive conntected to the HX-5102 SAVE "HEXBUS.101.T" actually on the 99/2 it should be: SAVE HEXBUS.101.T or SAVE HEXBUS.102.T i HOPE it is simply this (STUPID) issue! Maybe Michael can try the wrong command on the non-released 99/8-HX5102 combo MAME to see if he gets an error as well. In the end the ROM is different, so it might still be the issue even it that works on the 99/8.

a pic of the welcome screen is here http://atariage.com/forums/topic/247627-ti-998-and-more-collection-it-arrived/page-3?do=findComment&comment=3411906

there is a lot of terminal software for the TI-99. there is also emulation of a TI 820 and a TI 911 Terminal. Nevertheless I assume you are talking about a specific TE. with my 99/8 unit came a lot of software from the former owner and TI employee who was involved in testing Plato software it seems. I guess you have the Plato Terminal Emulator Software there to download from my preserved and shared disk images. both d021 and d036 are featuring the software: http://atariage.com/forums/topic/247627-ti-998-and-more-collection-it-arrived/page-3?do=findComment&comment=3412128 BR Klaus

if it really keeps failing even when reinstalling the original shugart drive into the HX-5102, I can still stick to the HexBus-RS232 and transmit the data over that port to my PC. It has worked the last time i dumped the first three banks with an external drive. maybe I did the termination wrong. In the end we have to succeed. So wish me luck tonight And another teaser: We might be able to see how a real 99/2 cartridge looks like.

I didn't buy a TI cartridge in the last 7 days.... where is my applause?

for some reason i always get i/o error 02 when trying to save any program to disk. i had the problem with the inner floopy in the hx-5102 from the beginning. i replaced the inner drive. now loading from internal hex-bus drive and external drive works but not storing anything, on both it doesn't work. i am currently sweating from switching out all kinds of configurations. i will not be able to do something tonight. maybe tomorrow morning before work.

oh my, voting here feels like: "hello, my name is klaus and i am a TI-holic!