kl99 Posted April 20, 2018 Share Posted April 20, 2018 (edited) 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. Edited April 20, 2018 by kl99 Quote Link to comment Share on other sites More sharing options...
kl99 Posted April 20, 2018 Share Posted April 20, 2018 And when going through that 99/2 manuals, I imagined the cassettte recorder SAVE option Quote Link to comment Share on other sites More sharing options...
kl99 Posted April 20, 2018 Share Posted April 20, 2018 Thanks. Let's just try and see what happens. The value E000 means that you have 4K RAM (E000-EFFF), which is more than originally designed (2K). This seems to be correct, looking at your photograph from the previous page. There are two 6116 chips, each one a 2Kx8 RAM. With 2K only, this would have become pretty ugly. 4K is not very much, in particular when you consider that 768 bytes are used for the screen, so effectively, you have 3328 bytes plus the 256 bytes from the CPU-internal RAM. The RAM in your system is from E000 to EFFF plus F000 to F0F9, plus FFFA to FFFF, minus the screen RAM at EC00 - EEFF. The byte at EF00 is a control byte for display. First we test to see whether the concept is working, later we can dump the bank completely. I'm not sure whether DATA lines take more or less space, so I take a direct poke instruction. I hope that the area from EF01 to EFFF is free to use; if not, something with crash, either the machine routine, or the BASIC program. Then we need to move to another location. Please add the following lines to your program at the beginning. They will place the routine at address EF40 and use a buffer at EF80. 1 CALL POKE(-4288, 2, 12, 224, 0, 29, 1, 2, 0) 2 CALL POKE(-4280, 64, 0, 2, 1, 239, 128, 2, 2) 3 CALL POKE(-4272, 0, 16, 204, 112, 6, 66, 22, 253, 4, 91) 4 CALL MCHL(-4288) ... your dump program ... This is intended to turn on the second bank, and to copy the contents of 4000-400F to EF80-EF8F (-4224 to -4209). You should then dump this address range. If it crashes, you can relocate that program to another location in E000-EBFF (-8192 to -5121). For that purpose, replace the target address in the POKE subprogram with another address, and also the address in MCHL. The buffer address is in the second line (239,128 = EF80 = -4224). You should also point that to another location and accordingly dump that new address. I am not sure whether the CALL MCHL is a BL which can be returned by RT (as done here). If it is a BLWP, we have to replace that with RTWP. Also, we could need to use SBZ instead of SBO. 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 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted April 20, 2018 Author Share Posted April 20, 2018 Tip: For conversions from hex to ascii and back, a string may come handy. For instance, PRINT SEG$("0123456789ABCDEF", MYVAL+1, 1) will deliver the character that represents the value of the hex digit. Quote Link to comment Share on other sites More sharing options...
kl99 Posted April 21, 2018 Share Posted April 21, 2018 (edited) -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] Edited April 21, 2018 by kl99 Quote Link to comment Share on other sites More sharing options...
kl99 Posted April 21, 2018 Share Posted April 21, 2018 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] Quote Link to comment Share on other sites More sharing options...
kl99 Posted April 21, 2018 Share Posted April 21, 2018 (edited) -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] Edited April 21, 2018 by kl99 Quote Link to comment Share on other sites More sharing options...
kl99 Posted April 21, 2018 Share Posted April 21, 2018 now i am dumping the content of the RAM via RS232 to look inside without changing the video memory content. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted April 21, 2018 Author Share Posted April 21, 2018 Thanks Klaus, your results prove that the specified layout is indeed correct. You should have RAM = E000 ... EFFF = 4 KiB Onchip RAM = F000 ... F0F9 and FFFA ... FFFF = 256 B Within the RAM, area EC00 ... EEFF is the screen buffer (768 B) EF00 is a control byte There should be a word that specifies the first free address outside of the BASIC program, which is said to be F00A (-4086), but this is apparently not true. We just need 26 bytes for the machine language program and a buffer for storing a copy of the bank. The bigger the bank, the less passes we need. However, since you now turned to byte transfer via RS232, we don't have to bother about too many files. If you have some assembler experience, you could modify the code of the machine language program to map in the second bank, copy the next byte to RAM, map it out, and send it via BASIC. Then you poke the next address into the machine program. Remember that I opted for copying the bytes because it could be that the bank is reset when returning to BASIC. 1 Quote Link to comment Share on other sites More sharing options...
kl99 Posted April 21, 2018 Share Posted April 21, 2018 (edited) 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. Edited April 21, 2018 by kl99 Quote Link to comment Share on other sites More sharing options...
kl99 Posted April 21, 2018 Share Posted April 21, 2018 Preliminary Memory Map, based on findings: 0000-1FFF ROM Bank #1...........8192 Bytes2000-3FFF ROM Bank #2...........8192 Bytes4000-5FFF ROM Bank #3...........8192 Bytes6000-7FFF not writable area.....8192 Bytes8000-9FFF not writable area.....8192 BytesA000-BFFF not writable area.....8192 BytesC000-DFFF not writable area.....8192 BytesE000-EBFF RAM...................3072 BytesEC00-EEFF RAM VDP Address Table..768 BytesEF00-EFFF RAM................... 256 BytesF000-F099 RAM................... 154 BytesF09A-F0A1 not writable area........8 BytesF0A2-F0AB RAM.....................10 BytesF0AC-F0C5 not writable area.......26 BytesF0C6-F0E3 poking crashes/breaks...30 BytesF0E4-F0FB RAM.....................24 BytesF0FC-FFF9 not writable area.....3838 BytesFFFA-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. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted April 21, 2018 Author Share Posted April 21, 2018 Could you add some REM statements, or a PRINT with a string of, say, 20 characters at least? This will make it easier to find locations in the BASIC program - one at the start, one at the end, maybe another in the middle. This BASIC is not compatible with our TI BASIC, because the subprograms (like PEEK) use tokenized subprogram names. In TI BASIC, the subprogram names are spelled out in memory. --- As I said above, there is on-chip RAM from F000 to F0F9. This is certainly writable, but you will likely collide with the BASIC system. Between F0FA and FFF9 there is nothing. I am a bit surprised that you found RAM at F0FA and F0FB. * The on-chip RAM is split in this strange manner because TI did not want to relocate the NMI vector (formerly called LOAD) at FFFC-FFFF. They also added the decrementer at the position before. *As I just checked, the decrementer does not count as RAM but as a separate register. Thus the on-chip RAM is at F000-F0FB, then at FFFA/FFFB there is the decrementer, and FFFC-FFFF is RAM, to be used by the NMI vector. 1 Quote Link to comment Share on other sites More sharing options...
+acadiel Posted April 21, 2018 Share Posted April 21, 2018 This is so cool. This little computer mystified me when I was younger, but when I heard how bare bones it was, I was like "They really were going to make that??" Still, it's really cool doing this.... I remember the thrill from the CC-40 when I finally got the banked ROM to dump. Stay with it, Klaus! 1 Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted April 21, 2018 Share Posted April 21, 2018 Happy to see that the RS232 transfer solution allowed to continue the operations :-) 1 Quote Link to comment Share on other sites More sharing options...
kl99 Posted April 21, 2018 Share Posted April 21, 2018 ok. back at the 99/2 now Quote Link to comment Share on other sites More sharing options...
kl99 Posted April 21, 2018 Share Posted April 21, 2018 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. Quote Link to comment Share on other sites More sharing options...
kl99 Posted April 21, 2018 Share Posted April 21, 2018 (edited) 0000-1FFF ROM Bank #1...........8192 Bytes2000-3FFF ROM Bank #2...........8192 Bytes4000-5FFF ROM Bank #3...........8192 Bytes6000-7FFF write protected.......8192 Bytes8000-9FFF write protected.......8192 BytesA000-BFFF write protected.......8192 BytesC000-DFFF write protected.......8192 BytesE000-EBFF RAM...................3072 BytesEC00-EEFF RAM VDP Address Table..768 BytesEF00-EFFF RAM................... 256 BytesF000-F099 RAM................... 154 BytesF09A-F09B write protected..........2 BytesF09C-F09D RAM......................2 BytesF09E-F0A1 write protected..........4 BytesF0A2-F0AB RAM.....................10 BytesF0AC-F0BB write protected.........16 BytesF0BC-F0BD RAM......................2 BytesF0BE-F0C5 write protected..........8 Bytes(F0C6-F0E3 poking crashes/breaks...30 Bytes)F0CE-F0D1 write protected..........4 BytesF0D2 breaksF0D3 RAMF0D4 breaksF0D5 RAMF0D6-F0D9 write protected..........F0DA-F0E1 RAMF0E2 RAM (screwed up output)F0E3 RAM (screwed up output)F0E4-F0FB RAM.....................24 BytesF0FC-FFF9 write protected.......3838 BytesFFFA-FFFF RAM......................6 Bytes enough for today. will continue tomorrow... Edited April 21, 2018 by kl99 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted April 21, 2018 Author Share Posted April 21, 2018 Klaus, as I mentioned above, please prepare a BASIC program with REM lines so that I can see the location of the lines in memory. You have to enter the lines in sequence to ensure that they keep their order im memory. You should use the same dump program as above. It is most important for us to identify the area where to put the machine language program without messing up the BASIC program. 1 Quote Link to comment Share on other sites More sharing options...
kl99 Posted April 22, 2018 Share Posted April 22, 2018 back on the 99/2. rs232 transfer got stuck on pc side again. arrgh restart Quote Link to comment Share on other sites More sharing options...
kl99 Posted April 22, 2018 Share Posted April 22, 2018 (edited) 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 SPACE60 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",OUTPUT110 FOR I=-8192 TO -3845120 CALL PEEK(I,P)130 H1=INT(P/16)140 H2=P-H1*16150 IF H1>9 THEN 180160 H1$=CHR$(48+H1)170 GOTO 190180 H1$=CHR$(87+H1)185 REM MIZAPF FIND THIS LINE190 IF H2>9 THEN 220200 H2$=CHR$(48+H2)210 GOTO 230220 H2$=CHR$(87+H2)230 PRINT #1:H1$;H2$;240 PRINT H1$;H2$;250 NEXT I260 CLOSE #1270 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. Edited April 22, 2018 by kl99 Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted April 22, 2018 Share Posted April 22, 2018 What are RS232 transfer parameters?Other thing. I hope that the SRAM chips on your 99/2 are OK. When I received mine, sometimes it was getting stuck or sent an INTERNAL ERROR when I launched programs. I tested the SRAM and one of them was unstable. I replaced it and now the computer works fine. Quote Link to comment Share on other sites More sharing options...
kl99 Posted April 22, 2018 Share Posted April 22, 2018 What are RS232 transfer parameters? "HEXBUS.20.B=9600.D=7.S=1.P=E" Quote Link to comment Share on other sites More sharing options...
kl99 Posted April 22, 2018 Share Posted April 22, 2018 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] Quote Link to comment Share on other sites More sharing options...
kl99 Posted April 22, 2018 Share Posted April 22, 2018 (edited) >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 Edited April 22, 2018 by kl99 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted April 22, 2018 Author Share Posted April 22, 2018 The program itself is relocatible, as it does not contain any branch to absolute addresses, so you can simply change the poke addresses and the address for the MCHL call. Also, the buffer may need to be put elsewhere. I mentioned this in http://atariage.com/forums/topic/277744-ti-992-questions/?p=4009986 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.