Jump to content

Photo

TI-99/2 questions


58 replies to this topic

#51 kl99 OFFLINE  

kl99

    Dragonstomper

  • 770 posts
  • Location:Vienna, Austria

Posted Yesterday, 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, Yesterday, 3:27 AM.


#52 kl99 OFFLINE  

kl99

    Dragonstomper

  • 770 posts
  • Location:Vienna, Austria

Posted Yesterday, 3:39 AM

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



#53 kl99 OFFLINE  

kl99

    Dragonstomper

  • 770 posts
  • Location:Vienna, Austria

Posted Yesterday, 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   0 downloads

 

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

110 FOR I=-4224 TO -4209



#54 mizapf ONLINE  

mizapf

    River Patroller

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

Posted Yesterday, 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

  • 770 posts
  • Location:Vienna, Austria

Posted Yesterday, 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, Yesterday, 11:58 PM.


#56 kl99 OFFLINE  

kl99

    Dragonstomper

  • 770 posts
  • Location:Vienna, Austria

Posted Today, 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

  • 770 posts
  • Location:Vienna, Austria

Posted Today, 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, Today, 2:09 AM.


#58 kl99 OFFLINE  

kl99

    Dragonstomper

  • 770 posts
  • Location:Vienna, Austria

Posted Today, 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 ONLINE  

mizapf

    River Patroller

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

Posted Today, 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.






2 user(s) are browsing this forum

0 members, 2 guests, 0 anonymous users