Jump to content

kl99

Members
  • Content Count

    1,055
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by kl99


  1. I am curious to discuss possibilities, theoretical and practical, about what could be changed/improved while staying with the 99/4A mainboard.

    And second what are the possibilities of a new Tms based Computers.

     

    We have seen the efforts that went into 99/8 and 99/2, the 99/4B, the 99/5, the 990 mini computers, the geneve, the 9995 breadboard by Stuart, the SGCPU by Snug, the TMS99105 fpga based computer by Erik.

    I am wondering on what could be achieved, if we are free to redesign everything around the CPU family.

     

    As far as I read it, TI did decide for many compromises when designing the 99/4A. We only have an 8 bit bus to the PEB. Most memory and devices are connected via 8 bit.

    Many Cpu signals are not passed onto the I/O Bus, or the signal is inverted.

     

    Afaik all the Cpus have an address range limitation of 64KByte. There are memory mapping possibilities that could bring us 16 (like the 99/8) or 64 MByte (like planned on the geneve 2).

     

    What would the best TI computer have as specs and can we create it?

     

    This also goes a bit into the direction when does it stop feeling special to all of us, when does it stop feeling like a TI.

     

    So some questions I can think of to start:

     

    Which Cpu should we pick? Will it be Fpga based to be able to overcome limitations that even the best Cpus have?

    Can we do a full 16 bit data bus and design a PEB using that or could we even use the existing PEB for a 16 bit data bus by switching to another interface card?

    How do we deal with the Grom approach used by most 99/4 software? We could only reuse the Grom0-2 chips from the 99/4A in higher numbers, but that would introduce dependencies to the grom system software part of the OS.

    Would the F18A be the video chip we want? Afaik the only limitation in comparison to the 9938 and 9958 is the video ram size.

    What would be the advantages/disadvantages or the VDP to be using Cpu Ram (like the 99/2).

     

    How would the memory map look like? I always feel a bit disappointed seeing on the 99/4A so much memory space is permanently assigned to Cartridge space, Console Rom, DSR Rom and the user (or an user program) can not use all 64k memory for a certain program.

    Can we copy the system rom from an Eprom chip into the RAM when the computer is turned on? Or is there a nicer approach?

    Are CRU based DSR the thing to go for? Or is there something smarter already?

     

    To also discuss the 99/4A topic:

    I am thinking on things like replacing the System ROM by fixed versions. Providing some Grom 0-2 replacement pluggable circuit. I was amazed by Matthew on his F18A. He stayed compatible to the mainboard while suddenly providing the 16K of Video Ram from his FPGA board, providing additional 2K of ram and providing direct access to the registers and video ram for the virtual Co Processor, a Tms9900. Or think of the solution that Erik Piehls showed where we attached his device to the I/O port and simulating a 640KByte cartridge (i think it was the XB2.7 suite) with having zero at the cartridge port and with having zero mods done to the mainboard.

     

    This intro might sound a bit fuzzy but so seems to by my knowledge on this hardware-dominated topic.


  2. Hi, this is Klaus. We managed to dump the 99/2 on the last weekend.

     

    So now it is time to complete the picture by also getting the other machines into the next preservation stage.

    We will try to dump the system roms of the never released/produced CC-40+, Compact Computer+.

    Steve Eggers is having one prototype unit and according to acadiel also ksarul is one prototype owner.

    The basic steps will be started off like acadiel managed to do all his dumps on the CC-40 unit.

     

    • Like 4

  3. Circuit Board is labeled with 1055197-1
    Eproms are stored on the sockets labeled
    U2 2x TMS 2564JL-45 MEP8327 (0000, 4000B)
    U3 1x TMS 2564JL-45 MEP8327 (4000)
    U12 1x TMS 2564JL-45 MEP8327 (2000)
    assignment according to page 1 of the TI992_Tech_Diagrams.pdf


  4. Here is the last Eprom, that was missing til now:

    romB-4000-5fff.bin

     

    dump-succeeder.bas

    1 GOTO 100
    10 CALL POKE(-7936,2,12,224,0,29,0,2,0)
    20 CALL POKE(-7928,94,0,2,1,225,128,2,2)
    30 CALL POKE(-7920,2,0,204,112,6,66,22,253,30,0,4,91)
    40 CALL MCHL(-7936)
    100 OPEN #1:"HEXBUS.20.B=9600.D=7.S=1.P=E",OUTPUT
    110 FOR I=-7808 TO -7297
    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)
    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

    Line 1 was commented out when I wanted to run the POKEs.

    Line 20 the first value after the address -7928 got increased by 2 to jump by 512 bytes.

    Each run transmitted 512 bytes over the Hex-Bus via the RS232 device.

    This was done 16 times to get 8192 bytes in total.

    Next step is verifying the ROM dump against the print out we have by making the binary match the formatting of the print out. This should reveal any diffs best.

     

    Many thanks to Mike Wright and M.Zapf!

    • Like 2

  5. ...
    3 CALL POKE(-7920,0,16,204,112,6,66,22,253,30,0,4,91)
    

     

    thank you a lot. it seems we are almost there. the program returned to the title screen. however the ram shows the correct values of the hidden(!) bank at -7808 to -7792.


  6. If it crashes with SBO 0, then this is more likely to be correct; it means it "cares" what bank is active. In that case we must reset it with SBZ 0 before returning.

     

    can you post how to change the program? I would be needing hours


  7. it did run now. will peek into the area to see if it did what we want :)

     

    1 CALL POKE(-7936,2,12,224,0,30,0,2,0)
    2 CALL POKE(-7928,64,0,2,1,225,128,2,2)
    3 CALL POKE(-7920,0,16,204,112,6,66,22,253,4,91)
    4 CALL MCHL(-7936)
    5 PRINT "DONE"


  8. yes, will do that Michael.

    However I peeked now in the expected area where we wrote the assembler code.

    That was still intact.

    And I peeked the 16 values from -7808 to -7791.

    It seems writing was done, it is matching the bank #3, however the non hidden one.

    0,0,6,160,38,88,6,160,38,42,200,2,234,98,4,224,242,29

     

    Yes, this is matching the first 32 hexadecimal values of the dump of bank 3. so the switching was not working, the copying DID work!

    00 00 06 A0 26 58 06 A0 26 2A C8 02 EA 62 04 E0


  9. yes, will do that Michael.

    However I peeked now in the expected area where we wrote the assembler code.

    That was still intact.

    And I peeked the 16 values from -7808 to -7791.

    It seems writing was done, it is matching the bank #3, however the non hidden one.

    0,0,6,160,38,88,6,160,38,42,200,2,234,98,4,224,242,29


  10. 1 CALL POKE(-7936, 2, 12, 224, 0, 29, 1, 2, 0)
    2 CALL POKE(-7928, 64, 0, 2, 1, 225, 128, 2, 2)
    3 CALL POKE(-7920, 0, 16, 204, 112, 6, 66, 22, 253, 4, 91)
    4 CALL MCHL(-7936)
    5 PRINT "DONE"

     

    Is this correct?

    It did crash.

     

    EDIT: edited to change the buffer to >E180

    Now it did RUN but there was it was not performing line 5, the PRINT command. Could it be that the assembly code exits wrong so there is no nice return to the basic prg?


  11. okay. i will try to relocate it now and check the results

    EDIT: poking all wanted values to E100 (-7936) was successful.

    Now I will try to run MCHL in addition.
    And if that works as well I will try to add my dump program.

×
×
  • Create New...