Jump to content

Photo

TI-99/2 questions


207 replies to this topic

#51 kl99 OFFLINE  

kl99

    Dragonstomper

  • 850 posts
  • Location:Vienna, Austria

Posted Fri Apr 20, 2018 3:25 AM

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 by kl99, Fri Apr 20, 2018 3:27 AM.


#52 kl99 OFFLINE  

kl99

    Dragonstomper

  • 850 posts
  • Location:Vienna, Austria

Posted Fri Apr 20, 2018 3:39 AM

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



#53 kl99 OFFLINE  

kl99

    Dragonstomper

  • 850 posts
  • Location:Vienna, Austria

Posted Fri Apr 20, 2018 2:39 PM

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.

 

Attached File  30743337_10214937059881645_4360310026498211840_o.jpg   251.2KB   2 downloads

 

Other than adding the 4 lines by mizapf the Line 110 got changed to

110 FOR I=-4224 TO -4209



#54 mizapf OFFLINE  

mizapf

    River Patroller

  • Topic Starter
  • 3,422 posts
  • Location:Germany

Posted Fri Apr 20, 2018 4:53 PM

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.



#55 kl99 OFFLINE  

kl99

    Dragonstomper

  • 850 posts
  • Location:Vienna, Austria

Posted Fri Apr 20, 2018 11:08 PM

-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 by kl99, Fri Apr 20, 2018 11:58 PM.


#56 kl99 OFFLINE  

kl99

    Dragonstomper

  • 850 posts
  • Location:Vienna, Austria

Posted Sat Apr 21, 2018 12:10 AM

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]



#57 kl99 OFFLINE  

kl99

    Dragonstomper

  • 850 posts
  • Location:Vienna, Austria

Posted Sat Apr 21, 2018 1:47 AM

-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 by kl99, Sat Apr 21, 2018 2:09 AM.


#58 kl99 OFFLINE  

kl99

    Dragonstomper

  • 850 posts
  • Location:Vienna, Austria

Posted Sat Apr 21, 2018 2:25 AM

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



#59 mizapf OFFLINE  

mizapf

    River Patroller

  • Topic Starter
  • 3,422 posts
  • Location:Germany

Posted Sat Apr 21, 2018 3:49 AM

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.



#60 kl99 OFFLINE  

kl99

    Dragonstomper

  • 850 posts
  • Location:Vienna, Austria

Posted Sat Apr 21, 2018 4:22 AM

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.

Attached File  e000-efff-prg-in-memory.bas   356bytes   2 downloads

It got transfered via LIST "HEXBUS.xxx..."

The dump output is this

Attached File  e000-efff.bin   4KB   2 downloads

Attached File  e000-efff-dump2.bin   4KB   2 downloads

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 by kl99, Sat Apr 21, 2018 4:47 AM.


#61 kl99 OFFLINE  

kl99

    Dragonstomper

  • 850 posts
  • Location:Vienna, Austria

Posted Sat Apr 21, 2018 5:27 AM

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.



#62 mizapf OFFLINE  

mizapf

    River Patroller

  • Topic Starter
  • 3,422 posts
  • Location:Germany

Posted Sat Apr 21, 2018 5:47 AM

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.



#63 acadiel OFFLINE  

acadiel

    Stargunner

  • 1,445 posts
  • www.hexbus.com
  • Location:USA

Posted Sat Apr 21, 2018 8:14 AM

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!



#64 fabrice montupet OFFLINE  

fabrice montupet

    Moonsweeper

  • 408 posts
  • Location:Burgundy - France

Posted Sat Apr 21, 2018 9:12 AM

Happy to see that the RS232 transfer solution allowed to continue the operations :-)



#65 kl99 OFFLINE  

kl99

    Dragonstomper

  • 850 posts
  • Location:Vienna, Austria

Posted Sat Apr 21, 2018 12:00 PM

ok. back at the 99/2 now



#66 kl99 OFFLINE  

kl99

    Dragonstomper

  • 850 posts
  • Location:Vienna, Austria

Posted Sat Apr 21, 2018 1:02 PM

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.



#67 kl99 OFFLINE  

kl99

    Dragonstomper

  • 850 posts
  • Location:Vienna, Austria

Posted Sat Apr 21, 2018 2:14 PM

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...


Edited by kl99, Sat Apr 21, 2018 2:15 PM.


#68 mizapf OFFLINE  

mizapf

    River Patroller

  • Topic Starter
  • 3,422 posts
  • Location:Germany

Posted Sat Apr 21, 2018 2:26 PM

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.



#69 kl99 OFFLINE  

kl99

    Dragonstomper

  • 850 posts
  • Location:Vienna, Austria

Posted Sun Apr 22, 2018 12:09 AM

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



#70 kl99 OFFLINE  

kl99

    Dragonstomper

  • 850 posts
  • Location:Vienna, Austria

Posted Sun Apr 22, 2018 1:07 AM

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

 

Attached File  e000-rem-sorted.bas   590bytes   2 downloads

Attached File  e000-rem-sorted.bin   4.25KB   2 downloads

Attached File  e000-rem-sorted-ver2-incomplete.bin   3.05KB   2 downloads

 

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 by kl99, Sun Apr 22, 2018 1:15 AM.


#71 fabrice montupet OFFLINE  

fabrice montupet

    Moonsweeper

  • 408 posts
  • Location:Burgundy - France

Posted Sun Apr 22, 2018 4:50 AM

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.



#72 kl99 OFFLINE  

kl99

    Dragonstomper

  • 850 posts
  • Location:Vienna, Austria

Posted Sun Apr 22, 2018 4:52 AM

What are RS232 transfer parameters?

 

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



#73 kl99 OFFLINE  

kl99

    Dragonstomper

  • 850 posts
  • Location:Vienna, Austria

Posted Sun Apr 22, 2018 4:58 AM

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]



#74 kl99 OFFLINE  

kl99

    Dragonstomper

  • 850 posts
  • Location:Vienna, Austria

Posted Sun Apr 22, 2018 5:10 AM

>E970:

 

Attached File  e970.png   6.45KB   2 downloads

 

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 by kl99, Sun Apr 22, 2018 5:48 AM.


#75 mizapf OFFLINE  

mizapf

    River Patroller

  • Topic Starter
  • 3,422 posts
  • Location:Germany

Posted Sun Apr 22, 2018 5:46 AM

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/...ions/?p=4009986






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users