9938/9958 Discussion Forum

[RXB]

Ok thanks. Guess now I need to figure out how to write a script to turn on the features I want in Mess.

 

First thing to do it get YAPP working so I can do a video of it, then see if I can get a XHi XB program to run that does not look like crap.

 

Is there any way to fix the EVPC so it has a better color pallet?

(As the video showed there is a huge problem here.)

[+InsaneMultitasker]

IMHO, the MESS setup questions and issues might be better served in a (the?) MESS topic, for folks with the same challenges in the future...

 

[sometimes99er]

IMHO, the MESS setup questions and issues might be better served in a (the?) MESS topic, for folks with the same challenges in the future...

 

I don't know. Emulation, issues, Classic99, MESS etc. have been on in topics for years, so I don't see any derailment as such from the 9938/9958 topic.

Edited December 3, 2013 by sometimes99er

[+mizapf]

I think it's not meant to be off-topic but it should be better preserved. I'm thinking about a section in ninerpedia. Still, it is not really easy to write a comprehensive manual that is at the same time quick and simple to read. The questions raised here may be interesting now, but the benefit of a sequence of questions and answers is not for sure. Pictures of FAQs with hundreds of entries come to my mind.

[RXB]

Well I am attempting to use the 9938 EVPC in MESS where the hell am I supposed to ask?

 

I thought the point of the Forums was to discuss things and help out?

 

Unless this topic is for hardware only. But I do not see any sense in creating a thread specifically for my question.

 

This is the first post by Kevan on 9938/9958 for this topic:

 

Go for it!

[+InsaneMultitasker]

 

I don't know. Emulation, issues, Classic99, MESS etc. have been on in topics for years, so I don't see any derailment as such from the 9938/9958 topic.

 

Agreed - I am only suggesting that with a MESS topic, there is better chance of someone finding the information in the future, versus inside a specific 9938/9958 topic. The questions and discussion have all been good and beneficial.

[RXB]

Ok but the question was about the EVPC emulation of the 9938 in MESS?

 

It would make more sense to get input from people that have one or a Geneve then people that just use the emulator only?

 

How would you troubleshoot a Emulator of hardware with no hardware peoples input?

[+InsaneMultitasker]

Ok but the question was about the EVPC emulation of the 9938 in MESS?

 

It would make more sense to get input from people that have one or a Geneve then people that just use the emulator only?

 

How would you troubleshoot a Emulator of hardware with no hardware peoples input?

 

I suppose you would need to also emulate the hardware people's input?

 

To answer your question, I was referring to MESS setup. Not EVPC emulation, not 9938 emulation. Only the steps required to install and start MESS. That initial setup has little to do with 9938 emulation but some of the thread could be very benefitial to a new MESS user.

 

And just for the record, just because my reply #77 followed your message #76 does not mean that I was replying to #76 specifically. Forum shortfall, I suppose.

Edited December 4, 2013 by InsaneMultitasker

[RXB]

Another Forum shortall is discussing your point without addressing anyone else's point.

 

My original point was the the color pallet from the video I posted showed the Color Palate is very wrong. (9938 EVPC in MESS)

 

I made the next point that Hardware people would be valuable in understanding why on MESS the Color Palate would be wrong and possibly how to fix it.

 

The discussion is still the 9938 and how it works. (MESS EVPC 9938 Emulation)

 

Moving this to MESS ONLY FORUM would not get input from hardware people or other 9938 users UNLESS they all USE MESS. See the problem?

[RXB]

And this is why I say that the 9938/9958 kicks the tail of F18 and 9918A

 

SCREEN SIZE

 

https://www.facebook.com/photo.php?fbid=10200498035008395&set=a.1248200260130.29061.1683172923&type=1

 

Also why I said it takes 4 TI99/4

Edited December 4, 2013 by RXB

[+InsaneMultitasker]

Another Forum shortall is discussing your point without addressing anyone else's point.

 

My original point was the the color pallet from the video I posted showed the Color Palate is very wrong. (9938 EVPC in MESS)

 

I made the next point that Hardware people would be valuable in understanding why on MESS the Color Palate would be wrong and possibly how to fix it.

 

The discussion is still the 9938 and how it works. (MESS EVPC 9938 Emulation)

 

Moving this to MESS ONLY FORUM would not get input from hardware people or other 9938 users UNLESS they all USE MESS. See the problem?

Mmm, no, you were originally posting about how crappy the video(s) looked, assumptions concerning how the 9938 hardware operates, difficulties setting up MESS, and option setup scripts.

 

I did not suggest or ask you to move the entire discussion to another forum or another thread in this forum. I did not suggest you move to a MESS ONLY FORUM. I did suggest the setup questions and issues would be better served as part of a MESS topic for others trying to set up MESS and I did agree with Sometimes99er's point that the discussion thread was beneficial. Please stop twisting my point in red into something it is not.

[microprocessor]

 

I have asked Michael some related questions but thought that I would post a bit to this thread. Perhaps one or more of you have come across information related to the 9938 VDP internal commands to move memory within VRAM or CPU<>VRAM. I have a puzzle that is driving me crazy!

 

In the Geneve OS, there are routines to generate a 16-color, 80-column text mode using bitmap graphics mode 6. I use this mode in my PORT terminal emulator to display color ANSI text/ibm graphics.

 

The logical CPU to VRAM move command is used to 'draw' each character, dot by dot. (I was confused about this because the manual shows pixels to bytes in one area, and dots in another). After some pondering I modified the OS routine into a standalone function. I then modified it from logical to high-speed move in an attempt to generate the character faster. I succeeded to a degree: my routine works and displays text slightly faster. But there is a troubling bit of code I do not understand.

 

The Geneve OS routines follow each byte of data with a second byte 0xAC. I searched MSX and other forums for an explanation. I scoured the 9938 manual and any technical data I could locate. I even came across an example (posted below) that shows this same byte being transferred in another non-TI/Geneve related routine... with no explanation.

 

If I remove the step of writing 0xAC to the 9938, the VDP will not process any further data. The system is held hostage until power down. I admit the explanation could be staring me in the face... but I can't see it. Best I can tell is this step may have been documented in a developers kit or some other unavailable-to-the-masses doc.

 

My intent is to speed up the drawing routine and couple it with the horizontal scroll register #23 to create a much faster terminal emulation. By creating a standalone routine, I also think it may be possible to port the 80-column color text routine to the other 9938/9958 devices used with the TI.

 

Here is the snip of code showing the 0xAC write by a non-TI/Geneve computer.

 

Any thoughts or ideas would be appreciated.

.waitvdp:       call ReadStatus         ; reads S#2
                bit 0,l
                jp z,.endvdp            ; the command is over
                bit 7,l
                jp z,.waitvdp           ; still not ready to transfer next byte
                inc de
                ld a,[de]
                out ($99),a
                ld a,128+44    ;****************  writing 172 to vram after each byte ******
                out ($99),a             ; write next byte to R#44
                jp .waitvdp             ; loop
.endvdp:        xor a
                call $00D8
                jr z,.endvdp            ; waits for spacebar pressed
                xor a
                call $005F              ; screen 0
                ret

the write of 172 is basically the write of r44 register, used to feed, byte per byte the data you want to transfer to VRAM. So you basically push on this register all the bitmap charater data. However this approach is not very efficient: to write a byte you are actually writing two bytes: the byte of image data, followed by the 0xAC (172) to tell vdp, 'please place the previous byte into r44 and perform vram byte transfer'. There is another approach:

You need to set the indirect register pointer to register44 (take care of disabling autoincrement mode for this register). So with a single I/O operation on a single port, you transfer all the bytes of your charater, doubling the speed. the code

 

ld a,[de]
                out ($99),a
                ld a,128+44    ;****************  writing 172 to vram after each byte ******
                out ($99),a             ; write next byte to R#44
                jp .waitvdp  

will change in:

 

ld a,[de] ' fetch the charater pattern
out (0x.....),a ; need to know the address where the direct register write port is mapped. but this will point always r44 after a proper setup
jp .waitvdp

 

if you can manage to have HL register pointing to charater pattern area you can manage to get more speed, loading C register with the right vdp port and perform a single OUTI instruction instead of ld a,[de], out (0x....),a

[microprocessor]

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.

The video show a demo that DOES NOT USE any of the v9938 features. While the v9938 is not the faster blitter on the earth, the drawing of lines or filling of rectangles and others operations suggest me that the demo performed gfx operations only using CPU, and probably not in the most optimized way one can do gfx using only cpu.

 

take for example two examples:

a) the block rectangle fill. the vdp can do logical fill operations at about 200Kpixels per seconds. at this rate, i should have not been able to see the 'fill operation' of the small colored rectangles in the demo.

b) the line drawing algorithm. the vdp uses hw acceleration to do lines on screen. the speed is enough that the human eye is not able to see the drawing process. in the video is clearly see the drawing process. this suggest me that the line draw algo is working ON CPU, and cpu is telling the vdp to turnon every single line pixel instead of telling vdp 'draw a line from (0,0)-(120,129)' for example.

I'm not surprised that a similar demo does not impress you.

[microprocessor]

 

The V9938 can execute "high speed" moves and fills based on coordinates, though they are limited to lines and rectangles and dots. There is nothing built-in to draw wire frames or circles directly. There are also no facilities to mimick a pattern table in the higher graphics modes, so one must plot the dots to create a character. Even with the high-speed routines, the amount of data necessary to display a simple 6x8 character is 50x that of standard text mode. Eck's code is using the built-in routines.

Partially correct, if you have a line primitive in hw you get advantage even drawing frames or poly. instead there is no facilities for circles however.

the demo does not probably use any of what the v9938 allow to use.

[microprocessor]

Incorrect. the v9958 is a improved v9938 basically.

displayed pixels are the same, if you sees some difference this does not depend on v99x8.

command speed is the same, relatively slow for doing full screen moves, adeguate to simulate sw-sprites of small sizes

the command engine is not 'compatible' but can be used even in G1 to G3 modes. A feature that under some degree could also be achieved on v9938 even with limitations.

[+InsaneMultitasker]

the write of 172 is basically the write of r44 register, used to feed, byte per byte the data you want to transfer to VRAM. So you basically push on this register all the bitmap charater data. However this approach is not very efficient: to write a byte you are actually writing two bytes: the byte of image data, followed by the 0xAC (172) to tell vdp, 'please place the previous byte into r44 and perform vram byte transfer'. There is another approach:

You need to set the indirect register pointer to register44 (take care of disabling autoincrement mode for this register). So with a single I/O operation on a single port, you transfer all the bytes of your charater, doubling the speed. the code

ld a,[de]
                out ($99),a
                ld a,128+44    ;****************  writing 172 to vram after each byte ******
                out ($99),a             ; write next byte to R#44
                jp .waitvdp  

will change in:

ld a,[de] ' fetch the charater pattern
out (0x.....),a ; need to know the address where the direct register write port is mapped. but this will point always r44 after a proper setup
jp .waitvdp

if you can manage to have HL register pointing to charater pattern area you can manage to get more speed, loading C register with the right vdp port and perform a single OUTI instruction instead of ld a,[de], out (0x....),a

 

Thank you. This makes sense and agrees with some of my later findings. The manner in which the bytes were being written confounded me, as did the auto-increment. It took some trial-and-error but I was able to make use of both methods you describe. Thank you for confirming and making this even clearer!!

[+InsaneMultitasker]

Partially correct, if you have a line primitive in hw you get advantage even drawing frames or poly. instead there is no facilities for circles however.

the demo does not probably use any of what the v9938 allow to use.

 

Hmmm.. I do not know of a way to program the V9938/9958 to draw a rectangle, polygon, or circle without drawing each point or line. I certainly would not want to draw lines by writing the individual bytes I think we agree here.

 

I suspect the video demo (not Eck's program) suffers from the program's BASIC component.

[JamesD]

 

Hmmm.. I do not know of a way to program the V9938/9958 to draw a rectangle, polygon, or circle without drawing each point or line. I certainly would not want to draw lines by writing the individual bytes I think we agree here.

 

I suspect the video demo (not Eck's program) suffers from the program's BASIC component.

You'd have to draw lines between the points that make up those shapes with the VDP and have the VDP fill them if necessary.

The demo clearly tries to do to much itself to accurately reflect what the 9938/9958 are capable of.

[microprocessor]

 

Hmmm.. I do not know of a way to program the V9938/9958 to draw a rectangle, polygon, or circle without drawing each point or line. I certainly would not want to draw lines by writing the individual bytes I think we agree here.

 

I suspect the video demo (not Eck's program) suffers from the program's BASIC component.

Not directly, of course. But a rectangle is made of 4 segments (or lines). So having the vdp primitive (line draw) it's not so difficult to have a square. Circle, obviusly is another thing, you need to draw by pixel, but having vdp to do this allow you to:

- avoid time-consuming operations needed to convert logical x-y coordinates to physical memory addresses

- avoid the inefficient (expecially on vdp like 'gpu') sequence needed to plot a pixel that is basically a sequence of : read, mask some bits (need to calculate also the mask), write

- you can parallelize operations, that is while vdp il plotting a pixel you can calculate x-y of the next. And with a 8 bit cpu you rarely can overrun the vdp, a single pixel plot can take about 5microseconds after you issued the command.

 

Of course the F18A is another thing, it does offer more ( and i would be surprised, if not, given the tecnological gap ), expecially sprites, the ever-weak-point of vdp's. But that's another story

[eck]

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.

[artrag]

I'm not sure to understand your question BTW MSX uses IN and and OUT instructions for accessing the VDP and all other standard peripherals (PSG for sound and PPI for keyboard and cassette).

 

AFAIK there are very few memory mapped devices and none of them in the standard plain msx configuration.

The sole memory mapped register in the msx standard is at 0xFFFF and allows memory slot configuration for machines with more than 32K of ram.

 

Just to have a glance of what the V9938/9958 allows with respect to the TMS9918A I would compare this (Space Manbow for msx2 and msx2+/TurboR )

 

http://www.youtube.com/watch?v=WKTzdRq6eOc&autoplay=1&rel=0&showsearch=0&showinfo=0&fmt=18&fs=1

 

With this (Nemesis III for msx 1):

http://www.youtube.com/watch?v=Nl8p49kbOrc

 

With Space Manbow, the sole difference between V9938 (MSX2) and V9958 (MSX2+ and TurboR) is that you see shaking borders on plain msx2, as the older chip does not have complete support for HW horizontal scrolling and does not offer HW borders

[eck]

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.

[artrag]

On MSX there are only two ports involved in VRAM access (other ports are used for palette):

 

- port 0x99 is used to set VRAM addresses and to signal if the next operation will be read or write. As for the TMS9918, you need to access to port 0x99 twice, writing low and high bytes of the VRAM address on 14 bit

 

- port 0x98 is used for reading and writing the actual data from and to the VRAM, so you can read and write from the same port, if I understand your question

 

Port 0x99 is also used for writing the VDP registers (as for the TMS9918). On V9938 bits 14-16 of the VRAM address are stored in a VDP register above R7. If you need to change the current vram address passing the 16K limit of the current accessed area, you have to use 0x99 four times. Twice to set the VDP register that holds the upper bits of the address and twice to set the lower 14 bits.

Edited January 10, 2014 by artrag

[kl99]

Whenever someones brings in 9938/9958 extensions for the TI-99 and compares them to the F18a, one should not forget that all those products were never about creating a chip, but creating an interface for an already produced video chip which was made by a professional chip company, being the project/solution mainly about the interface surrounding that chip.

In contrast to all those projects, the F18a project is about producing a video chip itsself, with a self-designed schematic, based on FPGA chip technology (#1, #2).

 

So actually you would need to compare all those 9938/9958cards with a not-yet-there PEB video card, equipped with 192k memory, that has a F18a in its VDP socket. Since the firmware of the chip can be modified, that should be doable. The question is, how many PEBs are out with active users to to get acceptance from the community to make such a project worth it. I see many 99ers going with the F18a/nanoPEB system as default setup now.

[Gazoo]

Whenever someones brings in 9938/9958 extensions for the TI-99 and compares them to the F18a, one should not forget that all those products were never about creating a chip, but creating an interface for an already produced video chip which was made by a professional chip company, being the project/solution mainly about the interface surrounding that chip.

In contrast to all those projects, the F18a project is about producing a video chip itsself, with a self-designed schematic, based on FPGA chip technology (#1, #2).

 

So actually you would need to compare all those 9938/9958cards with a not-yet-there PEB video card, equipped with 192k memory, that has a F18a in its VDP socket. Since the firmware of the chip can be modified, that should be doable. The question is, how many PEBs are out with active users to to get acceptance from the community to make such a project worth it. I see many 99ers going with the F18a/nanoPEB system as default setup now.

 

I'd snap one up in a New York minute if it were 9938 pin compatible and could access the 192k ram.

Somebody PLEASE make this device! Actually, I'll take 2 - one for my TI and one for my Geneve.

 

Gazoo