eck

(123) Tom Bentley is responsible for PrEditor.

Thanks, artrag! That is it, what I want to know. There are ports for writing purposes like >8C00, >8C02, >8C04 and >8C06 on the TI and ports to read from like >8800 and >8802. Interesting that the TI engineers used this way.

Hello, artrag! The TI 99 hardware uses different port addresses for reading and writing from and to the VDP. The Yamaha manuel of the V9938 is always talking about ports 0 to 3 regardless if they were speaking about reading or writing. It seems to me that MSX computers are using the same hardware addresses for both purposes. Maybe I misunderstood the manual here. My question is whether I am wrong or not.

Thanks, mate, for the corrections. Good to have you here, microprocessor! Your tip with VR17 is great. I was able to use it in the demo-program above. Can you tell me, what is wrong with VR17 and auto-increment? Someone mentioned it here in the thread. Do use the MSX-computers only one port-address for IN and OUT data from and to the VDP as the manual states? I do know only one computer with a slower BASIC-interpreter than the TI and this is the ZX 81/ Timex 1000. That is, what InsaneMultitasker is trying to say, when he writes: I suspect the video demo suffers from the program's BASIC component. My computer is to slow for MESS, but it might be an issue of the simulation speed of the V9938 in MESS too, is my suggestion.

Thank you, Rich! I watched your video and I am thinking that is it what we can expect from an extended basic program. I do know that there is a copy of XHI on my SD-card but I have no idea if the demo program is located there too, to confirm your supposition. I have to say one thing about the 255 to 256 fixed colors within the G7 mode: they are very "pinkish" missing earth tone colors like brown and grey. I remember watching .gif pictures made on other systems given them a look like taken out from a Barbie magazine. SNUG sold their EVPC with the option to add a RAM-DAC to the card which offers the user 256 color registers - and depending on the type of the RAM-DAC a color palette of 18 or 24 bits (original = 9 bits = 512 colors to chose from (G1 to G6)). So I wont wonder if this option is used in your mess setup. But starting by default with the 9 bits color palette would be the better way. I remember you were referring the differences between the V9938 and the V9958 pretty well somewhere in the forum. But sometimes you were using the wrong information found on the TI*MES website regarding the GENEVE 2 project. The V9938 has built in functions to read data from a mouse or light pen hooked to the right pins of the VDP. With the V9958 this functions are dropped to be able to install a 19K color mode with the chip. I never got my TIM card, so I have really no idea how OPA managed it to spend these device a mouse port. Both chips can handle 192K VRAM. The V9990 handles 512K. The V9958 has more squared pixels than the V9938. So, pixeled circles are looking more "cyclish" on a V9958 compared to the ones displayed by the V9938. All VDP commands are faster on the V9958 and a very good bonus is that they are now compatible with the G1 to G3 modes.

Hello, InsaneMultitasker! I played with the HMMM command. It is working fine. - Faster than the HMMC command that is obvious. Here are some suggestions: if You are going to plot all the ASCII-codes from 0 to 255 into the VDP-Ram in a 6*8 shape than there are 3 rows à 85 characters in use plus the fourth row starting with ASCII 255 and probably garbage afterwards. First suggestion: fill this row via HMMM with all text-lines that are useful in your program that fits into 84+ ASCII 255, which is a blank character in the EVPC-dsr-rom, and assign these sentences with one or more HMMM commands i.e. the needed data and plot, paint, stick them where ever you want. (Hope You can follow my crude explanations.) Second suggestion: change the HMMC command to plot 8*8 chars into VDP-Ram 64*4=256. The character definition is already 8*8 so the LI R6,3 and LI R6,4 have to be both incremented by one and the step counter changes from 6 to 8. Advantage is: avoiding the MPY statement times 6 to track down the right x position of the searched character. A slightly faster SLA R?,3 will do the trick here instead. There should be still enough room for whole sentences to hide in the VDP-Ram I think (see suggestion one.) If You have found the right x and y positions to copy from use only the 6*8 snippet with the HMMM command and plot it to your screen. Better stop here now. Ciao.

Nice! I will give the link you posted a try! Thanks a lot, TheMole. And, yes. I have a "Mandelbrot-Progamm" for the TI + V9938. I used to use it only to watch the pre rendered screens and played with the color options. Depending on the start values one would chose, the TI would be busy for 24, 48 hours and maybe more as I recall the description right.

Hello! My pcs did not have serial ports. I have to look, what a UDS-10 device is, to verify this option. I downloaded a pdf how the data on a .hfe-file is stored, but I did not understand a single word. Using Mess, saving on a pc99 disks, converting them to .hfe-files swapping SD-cards would not be the worst solution, I am thinking. Anyhow, I did not understand the cru magic myself. Simon Koppelmann's TMS 9900 Assembler book helped me. I searched the rom of the EVPC for the character definitions with a hex monitor program. I am using the absolute address, but it would be better using a look up table to get the address inside the rom. Any existing dsr rom could be enabled in the manner LI R12,>1x00, Set cru Bit to One on position >1x00/2 (+ operand 0 is reading SBO 0) and you can use the data stored at >4xxx. So with your Geneve follow my advise and use a ram or rom destination inside your system. Do not use this cru "Hokuspokus". Study your Geneve code to find the right address for port 3. Look were the "R17" data >91 is used to write data into other VDP registers. The code in the example above is not right. Change it to: UNTER1 MOVB *0+,*15. One reminder concerning my code when we are using commands: the number of bytes in consecutive order written to port 3 are X-1. The missing byte hides in the setup for the used command. That is the reason why I have to do things twice in a slightly different way. Maybe someone provides us a better solution to this problem? I think my printer cable is defect. Printing Hallo results in """"""""JCNNO. So OCR is no option for the moment. I copied the following code right away from the CRT. So we both have to remember the errors I made in the previous posts: DEF ST ST LWPI >B000 CLR 9 LI 13,>9100 LI 14,>8C02 LI 15,>8C06 MOVB @G6+1,@>83D4 MOVB 9,*14 BL @UNTERP DATA G6,12 MOVB @R36,*14 BL @UNTERP DATA LO,11 LI 12,>1400 this is 99/4A specific - skip this SBO 0 and this LI 2,>40E2 and adjust this to the first byte where your simple ASCII 0 definition starts ASCII0 CLR 8 preparing R8 ASCII1 LI 3,HMMC3+8 using a new setup for the HMMC command LOPO MOVB @LO,*3 clearing the location indicated by R3. Don't ask me if this is necessary. CLR 4 set R4 to zero LI 5,2 in one go we are shifting two bits LI 6,3 times 3-1 (reason is the X-1 byte I was talking about above)+1 (the position of * DEC 6 instruction takes the responsibility here) MOVB *2+,4 copies the first byte of ASCII code in R4 WIEDER SLA 4,1 JOC AN bit found? LI 7,HINTER-1 no, nibble for background color start position -1 AUCHAN A 5,7 nibble +1 or 2 equals to @HINTER, @HINTER+1 or new @VORDER and @VORDER+1 in any * combination AB *7,*3 nibble gets added to HMMC3+8 DEC 5 2 times? JNE WIEDER no JMP ERLEDI yes AN LI 7,VORDER-1 nibble for pixel color start position - 1 JMP AUCHAN I changed this while I was copying the text. It saves the * A 5,7 code * AB *7,*3 here * DEC 5 but * JNE WIEDER the old "pasta code" runs faster on every bit that is set ERLEDI BL @TSR2 test, if the VDP is busy. This might be obsolete? MOVB @R36,*14 HMMC+8 holds the first byte needed for VR44 BL @UNTERP DATA HMMC3,11 ERNEUT DEC 6 is R6 zero JEQ NEUER than 3*2 bits are done? INCT 5 no, so set R5 for an other two bits to shift CLR 3 preparing R3 WIEDE2 SLA 4,1 see above but using R3 to get the data for VR44 JOC AN2 LI 7,HINTER-1 AUCHA2 A 5,7 AB *7,3 DEC 5 JNE WIEDE2 JMP ERLED2 AN2 LI 7,VORDER-1 JMP AUCHA2 * A 5,7 * AB *7,3 * DEC 5 * JNE WIEDE2 ERLED2 BL @TR2 Important! Do not strip this. COC @MASK,9 JNE SCHLUS is HMMC3 done? HALT2 BL @TR2 no, go and check SR2 COC @MA,9 needs the VDP a pause? JNE HALT2 yes, than go to HALT2 MOVB 3,*14 no, copy byte into port 1 MOVB @R44,*14 assign it to the color register JMP ERNEUT go and see, if there is an other byte in the queue NEUER MOVB *2+,4 fetch the next byte from your basic char set definition LI 6,4 again 3 +1 JMP ERNEUT an other round SCHLUS AI 8,>0006 add 6 to the x position represented in R8 MOVB @>B011,@HMMC3 @>B011 equals to MyWorkspace+11 it is the low byte of R8 MOVB 8,@HMMC3+1 the high order bit of the x position DEC 2 I have to adjust R2 here CI 8,510 check if the x position is lower than #510. 85 chars per line JL LOPO not done yet CI 2,>48E3 I have had a counter here loaded with 3. 3*85=255 (0 to 254)chars in three rows. * My first thought was to add char 255 when the main loop is done. More pasta. * So I come up with this solution. The >48E3 was a little bit trial and error. * ASCII(255)*8+starting position of ASCII(0)+9. So, I didn't catch my logic for * myself. The disadvantage to the former solution is, that the routine is filling * the whole fourth line. JH C255 Make sure that we are testing the >L bit to make this bulletproof AB @PLUS8,@HMMC3+2 skip to the next row CLR HMMC3 start with x position zero JMP ASCII0 return. The JH C255 stops this routine C255 SBZ 0 here comes your own stuff ENDLOS JMP ENDLOS I am using my reset button here *ENDE MOVB @G1,+1,@>83D4 * MOVB @G1,*14 * BL @UNTERP * DATA G1,12 * B @>0000 UNTERP MOVB 13,*14 Videoregister 10010001 17 vorlegen MOV *11+,0 MOV *11+,1 DATA Werte abholen UNTER1 MOVB *0+,*15 Daten in Port 3 unterbringen DEC 1 JNE UNTER1 alle geschrieben? B *11 Ja, dann geht es zurück TSR2 MOVB @SR2,*14 MOVB @R15,*14 MOVB @>8802,9 COC @MASK,9 JEQ TSR2 B *11 TR2 MOVB @SR2,*14 MOVB @R15,*14 MOVB @>8802,9 B *11 MASK DATA >0100 der Befehl ist noch am ackern MA DATA >8000 der VDP ist noch beschäftigt G6 DATA >0A62,>3F00,>00F7,>3E07,>0A82,>0003 G1 DATA >00E0,>0020,>0006,>0007,>0802,>0000 LO DATA >0000,>0001,>0002,>D400,>FF00,>C0A6 sichtbaren Bereich mit Weiß füllen R38 EQU LO+11 LI DATA >0000,>0001,>0002,>0000,>0900,>70AC ist aus dem Programm geflogen LIX EQU LI+10 R44 EQU LI+11 R46 BYTE >AE R36 BYTE >24 SR2 BYTE 2 R15 BYTE >8F RS DATA >018E,>007A wird hier nicht mehr gebraucht HMMC2 DATA >0000,>0001,>0600,>0800,>FF00,>F000 HMMC3 DATA >0000,>4001,>0600,>0800,>0000,>F000 This is your data pool. >4001 prints the chars on * screen. To hide the chars alter this values (byte 1 * and 2) >01 indicates the second page I am using with * G6 setup no sprites. PLUS8 EQU HMMC3+6 VORDER DATA >0110 Schwarz HINTER DATA >0000 Transparent END Well, I hope that I did not do any other copying errors.

Sorry, but I am not able to transfer data between my TI and my Pc other than with .hfe-files. They are containers used by the HxC Floppy Emulator. Maybe someone with a HxC and the ability to transfer the data to a Pc might help us? I can convert .dsk-files on a Pc, safe them on a SD-card and use them with my Corcomp controller. But the other way round did not work for me in the past. Looks like an one-way solution. I am in the same situation as Owen. My system fails from time to time. I have to learn how to use Mess then the data-transfer problem would no longer exist. Sometimes ... You are writing that the Geneve routine writes a rectangle (space?) and then writing 48 dots in series? Even(?) if someone uses the LM.. commands to print data to the screen, setting the right logical bit(s), makes a space write redundant, this is my thinking - feeling (we have to proof my feelings). They are great commands to generate colorful software sprites of any size. Please be patient with the routine to pre-process the characters. I have my handwritings in front of me with the thoughts to program it, but they are hard to understand, even for the author himself. I hope that my denglish won't hurt you to much. Here is my translation attempt: DEF ST ST LWPI >B000 Workspace setting for debugging purposes - bad style CLR 9 the hi-byte of register 9 will be used to check status bits from SR2 of the MSX video chip LI 13,>9100 fixed register hi-byte contains VR17 for VWTR purposes LI 14,>8C02 fixed register with port 1 LI 15,>8C06 fixed register with port 3 MOVB @G6+1,@>83D4 copy of VR1 for the time out routine of the TI99/4A MOVB 9,*14 at the moment R9 is cleared so the routine to write VDP registers will * start with VR0 BL @UNTERP this routine uses R0, R1, R11, R13, R14 and R15 DATA G6,12 12 video registers to write preset data - use your own routine here MOVB @R36,*14 using the same routine but transfer data to * 11 consecutive command registers BL @UNTERP DATA LO,11 preset data to clear the visible screen area * - change the color register to your own preferences VR44 set with >FF BL @TSR2 this subprogram checks if the command is done and than will return MOVB @R36,*14 * here you find code which should help me to track down the errors I made BL @UNTERP * skip this DATA HMMCA,11 * displays a pre calculated A 6*8 black (1) and transparent (0) LI 0,ASCA * recycles R0 to point to the pre calculated char definition SCHR3 BL @TR2 * a different version of the @TSR2 sub program - checking R9 inside the * main program COC @MASK,9 * important check here while testing the end of the command JNE FERTI * if the bit found in @MASK is reset in R9 representing SR2 then we are * done HALT3 BL @TR2 * this is the flowchart I found in the manual, so the VDP might be fast * enough to skip this bit checking - I never tried this without it COC @MA,9 * check the bit if the VDP is busy or not JNE HALT3 * busy here jump to hold on3 wait MOVB *0+,*14 * ready to pump the data R0 is pointing to to port 1 MOVB @R44,*14 * direct these data to VR44 to make the command work JMP SCHR3 * go to check, if the command is done FERTI LI 12,>1400 * setting R12 with the cru of my video-card - obsolete on a geneve FERTIG MOVB 1,*14 * writing my card game I noticed that is not a bad practice to read SR2 * from time to time - I think you can skip these too MOVB @R15,*14 * starting a read of SR0 R1 is 0 at this time MOVB @>8802,0 * do the read and forget the thing MOVB 1,@>8374 prepare the TI for a key scan MOVB 1,@>837C GPL status cleared TASTE BLWP @>2108 E/A KSCAN MOVB @>837C,1 is any key pressed? JEQ TASTE no go to TASTE CLR 2 prepare R2 MOVB @>8375,2 move the ascii code in hi-byte of R2 SRL 2,5 while the value is in the hi-byte, a right shift by 5 equals to *8 AI 2,>40E2 bad practice to use the absolute address here but with your Geneve you * have to use here a ram, rom address with the character definition you * want to start with: CALL CHAR(30,"0078787878787878") you get the * picture. I am using the null character as the starting point. The key * value times 8 gives us the position of the ascii based on our ram, rom * starting position. LI 3,HMMC2+8 we want to use the HMMC command and the label contains the needed data * to write a 6*8 char. x position 0 and y position 256 are preset * (second page first visible area). We have to manipulate the byte at * HMMC2+8 with the first byte of the selected character. Remember that * this is forced by the way I used to set up the commands of the VDP MOVB @LO,*3 get rid of an old entry at HMMC+8; I think you can skip this CLR 4 preparing R4 LI 5,2 two bits of the old charset will be used for one byte LI 6,3 3 pairs are used for a 6 pixel wide char but during the command setup * I have to strip one (3-1) but the position of the DEC 6 makes an extra * count, so we are again with LI 6,3 SBO 0 * strip this on the Geneve MOVB *2+,4 VERDAMMT I forget to copy this, so this is the point you might stumble * over. Copies the first byte of our character to write in the HMMC+8 * position. SBZ 1 * related to source of my TI data. see SBO 0 WIEDER SLA 4,1 here we go to check our bits JOC AN is a bit shifted out then a pixel is set within the character definition. Go to* label AN LI 7,HINTER-1 no pixel is set, so HINTER-1 prepares the color to be set if the bit is 0. * Remember our R5 starts with 2 decreases to one and than the loop is over. A 5,7 our color code is build by two nibbles in a reversed order. I have preset the * values to >00 00. The first nibble contains the color of the second shifted bit AB *7,*3 one of the preset data is put into HMMC2+8 DEC 5 did we handle 2 bits yet? JNE WIEDER no, do it again JMP ERLEDI yes, see what is next AN LI 7,VORDER-1 if the sla jocs us here A 5,7 find the preset color nibble AB *7,*3 add it to HMMC2+8 DEC 5 JNE WIEDER ERLEDI BL @TSR2 * check, if the VDP is ready. I think you can skip this here. * But this is the save way. MOVB @R36,*14 we can now start our HMMC command.HMMC+8 is ready BL @UNTERP DATA HMMC2,11 ERNEUT DEC 6 here I am one ahead. But we load R6 with 3 and we have no to worry JEQ NEUER did we expand every 6 bits? INCT 5 no, R5 equals to 0 but we need it to have 2 in it. CLR 3 R3 gets a new task WIEDE2 SLA 4,1 this is the same routine as above, but now VR44 will get its bytes. JOC AN2 LI 7,HINTER-1 A 5,7 AB *7,3 DEC 5 JNE WIEDE2 JMP ERLED2 AN2 LI 7,VORDER-1 A 5,7 AB *7,3 DEC 5 JNE WIEDE2 ERLED2 BL @TR2 this is important here COC @MASK,9 JNE SCHLUS we are checking, if the command is over? Yes, go to SCHLUS HALT2 BL @TR2 no, but you might skip this for faster execution. COC @MA,9 see the flow chart in the manual JNE HALT2 of the HMMC command MOVB 3,*14 we are writing our bit crushing to port 1 MOVB @R44,*14 and directing it to VR44 - color register JMP ERNEUT go and check the content of R6 NEUER SBO 0 skip this MOVB *2+,4 R2 must point to your character definition SBZ 0 skip this LI 6,4 when the setting of HMMC+8 is done and the 4 remaining bits are processed than * we have to work on 3*2 bits. Due to the position of the DEC 6 the 3 is * incremented to 4 JMP ERNEUT do it again, Sam SCHLUS B @FERTIG here starts the logic to write all chars into the VRAM you need. *ENDE MOVB @G1,+1,@>83D4 * MOVB @G1,*14 * BL @UNTERP * DATA G1,12 * B @>0000 UNTERP MOVB 13,*14 Videoregister 10010001 17 vorlegen MOV *11+,0 MOV *11+,1 DATA Werte abholen UNTER1 MOVB *0+,15 Daten in Port 3 unterbringen DEC 1 JNE UNTER1 alle geschrieben? B *11 Ja, dann geht es zurück TSR2 MOVB @SR2,*14 MOVB @R15,*14 MOVB @>8802,9 COC @MASK,9 JEQ TSR2 B *11 TR2 MOVB @SR2,*14 MOVB @R15,*14 MOVB @>8802,9 B *11 MASK DATA >0100 der Befehl ist noch am ackern the command is being executed MA DATA >8000 der VDP ist noch beschäftigt VDP is busy G6 DATA >0A62,>3F00,>00F7,>3E07,>0A82,>0003 G1 DATA >00E0,>0020,>0006,>0007,>0802,>0000 LO DATA >0000,>0001,>0002,>D400,>FF00,>C0A6 sichtbaren Bereich mit Weiß füllen R38 EQU LO+11 LI DATA >0000,>0001,>0002,>0000,>0900,>70AC ist aus dem Programm geflogen not used anymore LIX EQU LI+10 R44 EQU LI+11 R46 BYTE >AE R36 BYTE >24 SR2 BYTE 2 R15 BYTE >8F RS DATA >018E,>007A wird hier nicht mehr gebraucht not used here artefact HMMC2 DATA >0000,>0001,>0600,>0800,>FF00,>F000 VORDER DATA >0110 Schwarz color code black HINTER DATA >0000 Transparent HMMCA DATA >0700,>0001,>0600,>0800,>0000,>F000 aus 06 wird 3 means there are only 3 bytes involved ASCA DATA >0000,>0011,>1001,>0001,>0100,>0101,>1111 DATA >0100,>0101,>0001,>0100,>1000 END

Rich, please remember that the f18 runs at 100MHz while the V9938 runs on ~21MHz. Your V9958 TIM-board did a better job than mine V9938 card today. And do not forget that the TMS9900 is slower than the Z80 used on MSX computers. So the bigger VDP RAM can be a disadvantage depending on the things to do. I took Bruce Harisons shuffling routine - published in MICROPendium - to write a card game using G4 mode (32K VRAM). Harald Krafthöfer told me that the graphics were to small. He is right, but changing the program to G6 mode would more than double the amount of data used with the commands of the VDP. And the V9938 commands take their times, believe me. But here is an other one: Does anybody knows the status of the Geneve2? I would give "him" a try.

Mister ... Multitasker, hello! You are right, I have the picture on page 7 in my mind regarding the VR23. I am using code from Alexander Hulpke which sets the VDP-Write-Adress that allows you to poke into the whole VRAM plus expansion RAM. His code was published in a german user magazin. There he mentioned his trouble having with the VRAM usage "below" the grafic modes G4 to G7. I have had this trouble too, because my program failed in seting all these promissed video pages in G1 mode. In his article I read the explanation: from G1 to G3 and in both text modes every fourth byte is used in the 64K VRAM of the MSX2 video-chip. One used byte, three unused bytes and so forth. I think this is the reason why the VR23 can not handle the text mode scrolling properly. I spotted a hint from Tursi here in the forum wich might change that behavior of the standart modes of the TMS9918 plus Text2 mode. Though, I did not tried it out yet.Here is an other point: I changed my posted code above to display 255 characters found in the ROM of the EVPC-Card. Well, all that heavy bits and byte crunching, VDP-adress-changing slows it visible down. With a 6*8 charset there are 85 chars per row with 1*8 pixels spared. 3 rows à 85 chars totals to 255. ASCII 255 would become the first character on the fourth row. I have no idea which character size you are using for your terminal program. But for now I stoped thinking about an easy way to find the right x- and y-coordinates to use them with the HMMM command with the character setup my program has produced. If you are thinking about "proportional Schrift (font)" then you are forced to use the LM.. commands with in the G4 to G6 modes. Wish you success.

Huh! That confuses me like the V9958 manual. Lets say, if you wrap around the top line of the screen to the bottom of the non visible screen ( i. e. from 0 or what value is the top line number to 255) than the VRAM content after the last visible line 192+1 or 212+1 should not become part of the visible screen. I am talking about the V9938 - with the V9958 there is a way - or I misunderstand the manual of the V9938 at this point. It would be nice if it works like you were telling me.

" ... die Jungs aus Buxtehude und aus Lüneburg ..." Schaltpläne habe ich nicht, aber bei einem konspirativen Treffen könnte ich Ihnen meine Kiste aushändigen, um mal einen vergleichenden Blick werfen zu können. Schwer zu koordinieren, aber nicht unmöglich. I have no schematics, but a cps you can look at it.

Hut ab Lady, grandioser Vortrag. Merci, Michael.

Hello, Mr. InsaneMultitasker! You might quiet catch this, but the VR23 provides no scrolling with the V9938. We can alter the starting position of the screen-top. Don't ask me if this has any use. The V9958 has a scrolling register, but I have no idea how to use it, if I would own one. I can not follow the description in the manual. For scrolling purposes the YMMM might be the best command with the V9938. I did not test this, yet. To speed things up in your program take a look at the HMMM command. A full blown 6*8 character set needs a space of >1800 bytes in the VRAM. I post a not so useful code which is working with the EVPC from the SNUG. The program does not do much, but it might be worth a short look. DEF ST ST LWPI >B000 CLR 9 LI 13,>9100 LI 14,>8C02 LI 15,>8C06 MOVB @G6+1,@>83D4 MOVB 9,*14 BL @UNTERP DATA G6,12 MOVB @R36,*14 BL @UNTERP DATA LO,11 BL @TSR2 MOVB @R36,*14 BL @UNTERP DATA HMMCA,11 LI 0,ASCA SCHR3 BL @TR2 COC @MASK,9 JNE FERTI HALT3 BL @TR2 COC @MA,9 JNE HALT3 MOVB *0+,*14 MOVB @R44,*14 JMP SCHR3 FERTI LI 12,>1400 FERTIG MOVB *1,*14 Statusregister 0 MOVB @R15,*14 zur Sicherheit MOVB @>8802,0 lesen MOVB 1,@>8374 MOVB 1,@>837C TASTE BLWP @>2108 E/A KSCAN MOVB @>837C,1 JEQ TASTE CLR 2 MOVB @>8375,2 SRL 2,5 KEYSCAN *8 AI 2,>40E2 ASCII 0 des ROM-Zeichensatzes der EVPC für T2-Mode LI 3,HMMC2+8 zu manipulierende Adresse MOVB @LO,*3 Adresse erst einmal löschen CLR 4 LI 5,2 zwei Bit für ein Byte LI 6,3 mal 3-1+1 (2*3=6*8 Zeichen) SBO 0 ROM einschalten WIEDER SLA 4,1 JOC AN ist ein Pixel an? LI 7,HINTER-1 nein, also Hintergrundnibble vorbereiten A 5,7 Nibble +1 oder 2 AB *7,*3 Nibble landet auf HMMC2+8 DEC 5 SCHON 2*? JNE WIEDER nö JMP ERLEDI ja AN LI 7,VORDER-1 bekannte Prozedur für ein gesetztes Pixel A 5,7 AB *7,*3 DEC 5 JNE WIEDER ERLEDI BL @TSR2 ist an dieser Stelle sicher überflüssig MOVB @R36,*14 HMMC+8 ist jetzt einsatzbereit BL @UNTERP DATA HMMC2,11 ERNEUT DEC 6 Vorabzug, daher 3-1*+1 JEQ NEUER 3*2 schon abgearbeitet? INCT 5 nein, also 5 wieder auf zwei setzen CLR 3 WIEDE2 SLA 4,1 Bits testen für die folgenden Datenbytes JOC AN2 LI 7,HINTER-1 A 5,7 AB *7,3 DEC 5 JNE WIEDE2 JMP ERLED2 AN2 LI 7,VORDER-1 A 5,7 AB *7,3 DEC 5 JNE WIEDE2 ERLED2 BL @TR2 wichtig an dieser Stelle COC @MASK,9 JNE SCHLUS ist HMMC2 fertig? HALT2 BL @TR2 nein, aber dies hier ist vielleicht auch überflüssig? COC @MA,9 JNE HALT2 MOVB 3,*14 das Colorregister mit Daten füttern MOVB @R44,*14 JMP ERNEUT NEUER SBO 0 MOVB *2+,4 weiteres Byte aus dem ROM holen SBZ 0 LI 6,4 drei Durchläufe, dank Vorabzugs +1 JMP ERNEUT noch 'ne Runde SCHLUS B @FERTIG endloses Programm, bereit für neuen Tastendruck *ENDE MOVB @G1,+1,@>83D4 * MOVB @G1,*14 * BL @UNTERP * DATA G1,12 * B @>0000 UNTERP MOVB 13,*14 Videoregister 10010001 17 vorlegen MOV *11+,0 MOV *11+,1 DATA Werte abholen UNTER1 MOVB *0+,15 Daten in Port 3 unterbringen DEC 1 JNE UNTER1 alle geschrieben? B *11 Ja, dann geht es zurück TSR2 MOVB @SR2,*14 MOVB @R15,*14 MOVB @>8802,9 COC @MASK,9 JEQ TSR2 B *11 TR2 MOVB @SR2,*14 MOVB @R15,*14 MOVB @>8802,9 B *11 MASK DATA >0100 der Befehl ist noch am ackern MA DATA >8000 der VDP ist noch beschäftigt G6 DATA >0A62,>3F00,>00F7,>3E07,>0A82,>0003 G1 DATA >00E0,>0020,>0006,>0007,>0802,>0000 LO DATA >0000,>0001,>0002,>D400,>FF00,>C0A6 sichtbaren Bereich mit Weiß füllen R38 EQU LO+11 LI DATA >0000,>0001,>0002,>0000,>0900,>70AC ist aus dem Programm geflogen LIX EQU LI+10 R44 EQU LI+11 R46 BYTE >AE R36 BYTE >24 SR2 BYTE 2 R15 BYTE >8F RS DATA >018E,>007A wird hier nicht mehr gebraucht HMMC2 DATA >0000,>0001,>0600,>0800,>FF00,>F000 VORDER DATA >0110 Schwarz HINTER DATA >0000 Transparent HMMCA DATA >0700,>0001,>0600,>0800,>0000,>F000 aus 06 wird 3 ASCA DATA >0000,>0011,>1001,>0001,>0100,>0101,>1111 DATA >0100,>0101,>0001,>0100,>1000 END

OPA announced a TMS99xxx processor plug in for the console in MicroPendium with 12 MHz operation speed. As far as I remember the board should be clipped just over the 9900. I ordered a TIM and hoped to buy these device too, but the TIM was not shipped to me and the 'Speedboard' was never released. A few days back I was looking for the SBP9989NL (4.4MHz, 64 pin, 16 bit data bus, 9995 instruction set, 128K ram addressable, ... ) on the internet, if it might be a replacement for the TMS9900 in the console, but the price is exorbitant. So this is cancelled. There was also an advertisement in MicroPendium issues about a p-box card with a forth microprocessor on it, which promised a lot of speed. Sad to say that nobody ordered this card.

Correct, Sir.

127 files on TI-formatted disks is the maximum, I think. Your work looks very promising.

Hi! I transfered my floppies on SD-Cards with a HxC device. Thanks to Mr. Guidry, who mailed me a blank pc99 DSDD disk in times, when it was the only format to write on a SD-Card. The issue, why I post here is: there is actually no way to reconvert the .hfe-files, used along with the HxC, into pc99-files. I saved my disk-images in .hfe-format on my pc, but they can not be used in emulators. I think somebody tries to enhance the software written for use with the HxC-device in that direction, but I am not able to tell the status about this project. I had problems with other image-formats other than the pc99, maybe this is fixed so far, cannot tell either. It is no easy decision, but I think you should know this about the HxC-system. I like it.