F18A

[microprocessor]

Ha! You are on to me. It will be interesting to see what the MSX and CV people think about the 9900-based core. I did seriously consider a lot of other options, especially using something like a Z80 or 6809 core since they already exist.

-...........

I will be very interested to see what people do with it

because it's a 9900 core, the only people that can gain are tms users. others will be lazy in learning.

Personally, instead of a general cpu core, i would have liked more a specialized graphics core. However, with pattern mode based vdp and the color spill problem bit blitting is somewhat useless...

Edited March 28, 2012 by microprocessor

[Willsy]

You'd be surprised at how simple 9900 programming is. Having had some experience with Z80 assembly language (ZX Spectrum) I can say that (IMHO!) 9900 is much simpler than Z80. And we'd be only too happy to help our MSX and Colecovision friends with any 9900 questions.

[microprocessor]

You'd be surprised at how simple 9900 programming is. Having had some experience with Z80 assembly language (ZX Spectrum) I can say that (IMHO!) 9900 is much simpler than Z80. And we'd be only too happy to help our MSX and Colecovision friends with any 9900 questions.

Simple or not, programmers are somewhat lazy. I know ( but i'm another kind of beast ) a little of 9900 assembly & architecture, but honestly i think most people are too much entailed to their own roots. so probably there is not much interest in using the cpu core. The interest for F18A as a pure VDP replacement can be good.

[kl99]

i don't agree with you microprocessor. we are talking about people who are programming 30 year old systems. like in the old days, every byte counts, speed counts. it's all about memory and efficiency. taking the challenge and programming on such systems doesn't allow lazyness. lazy programmers simply won't choose such old systems.

 

of course there will be programmers who will prefer to have compatibility with non-f18a users and therefore won't touch any of the features.

but there will be programmers who will want to utilitize the enhanced features of the f18a, and they will go full road and love the co-cpu!

 

and as far as i understood, you can even make your program the best of both worlds: there is a way from assembler to determine if your machine is a f18a unit. this way you can make a program that uses f18a features in case it is run on a f18a unit.

[+OLD CS1]

So, do I read correctly that the F18A is programmable in TMS-9900 assembly?

[Willsy]

So, do I read correctly that the F18A is programmable in TMS-9900 assembly?

 

Yes!

[microprocessor]

i don't agree with you microprocessor. we are talking about people who are programming 30 year old systems. like in the old days, every byte counts, speed counts. it's all about memory and efficiency. taking the challenge and programming on such systems doesn't allow lazyness. lazy programmers simply won't choose such old systems.

you are mixing lazyness in learning a new assembly language or uP architecture

with the passion every old-programmer have for squeezing those ancient beasts.

They are totally different things.

There are also some purists that do not accept the idea of a new "cpu" that is so 'powerful'. they love to squeeze every bit to the old one CPU. But this is another story

Edited March 30, 2012 by microprocessor

[TEXAS_JOE]

I've been thinking about that very subject myself tonight, before I read this post. Regarding squeezing the ancient beasts.

(was on the phone discussing why i do retro computers to a friend)

 

I think you'll find practically every programmer on here myself including find the older machines a lot more fun than coding modern architecture.

Nothing surprises me about 'modern' computers anymore. 32-bit and 64-bit with bells and whistles attached. No thanks. They're boring.

I would'nt say any of us are 'lazy' for not learning a new assembly language, we just choose not to. It's about preference, not wether we're lazy or not.

 

That said, I am a TI-99 purist.

[matthew180]

Over the weekend I had a chance to finally test in a Tommy Tutor that was loaned to me. Like the CV, the 9918A is soldered to the board, so I first had to remove it and install a socket. So far I have gotten lucky in that the orientation of the 9918A is such that the F18A board fits pretty well. In the case of the Tommy, if the 9918A had been the other direction, the F18A would not have fit inside the original case / shielding. Also like the CV, the taller pins I have on one of my test F18A boards comes in handy, and I'm probably going to have a "taller pins" option for people using the F18A in certain systems.

 

Here are some photos. I also have an ADAM system I'm currently testing with, and things are working fine. However, like my CV, the ADAM requires two controller to be plugged in before the system will recognize the button presses. I've been told the CV's controller I/O is quirky like that... I hope that is the case and not some other strange behavior of the 9918A that I need to eek out.

[Tempest]

However, like my CV, the ADAM requires two controller to be plugged in before the system will recognize the button presses. I've been told the CV's controller I/O is quirky like that... I hope that is the case and not some other strange behavior of the 9918A that I need to eek out.

What do you mean two controllers need to be plugged in before it recognizes button presses? You mean only when the F18A is installed?

[matthew180]

Correct. In the CV I have, and the ADAM you loaned me, the buttons (left, right, and number pad) are not recognized unless I have two controllers plugged in. Another CV owner said that this was not uncommon and that CV's were known for quirky controller I/O.

 

It seems that certain timing (particularly the vertical interrupt) on the original VDP's (9918A, 9928, 9929) was not as exact as the F18A. This was discovered recently due to a bug in the 99/4A Pole Position that was found, thanks to Tursi, that was causing the game to hang with the F18A. I added some deviation as to when the vertical interrupt was sent and the game began to work normally. I suppose it is possible that the amount of deviation on the original VDP's was even greater than what I added, and the CV / ADAM expose that anomaly even more than Pole Position did. It is just a hunch though, and on my list of things to try when I get a chance.

 

Maybe with two controllers the CV's interrupt service routine has a little more code to execute and changes the timing of things when just one controller is plugged in.

 

[opcode]

Correct. In the CV I have, and the ADAM you loaned me, the buttons (left, right, and number pad) are not recognized unless I have two controllers plugged in. Another CV owner said that this was not uncommon and that CV's were known for quirky controller I/O.

 

It seems that certain timing (particularly the vertical interrupt) on the original VDP's (9918A, 9928, 9929) was not as exact as the F18A. This was discovered recently due to a bug in the 99/4A Pole Position that was found, thanks to Tursi, that was causing the game to hang with the F18A. I added some deviation as to when the vertical interrupt was sent and the game began to work normally. I suppose it is possible that the amount of deviation on the original VDP's was even greater than what I added, and the CV / ADAM expose that anomaly even more than Pole Position did. It is just a hunch though, and on my list of things to try when I get a chance.

 

Maybe with two controllers the CV's interrupt service routine has a little more code to execute and changes the timing of things when just one controller is plugged in.

 

I fail to see the connection. Have you tried the ADAM with a regular 9928? Does the same issue with the controllers happen. All my CVs work with a single controller plugged in.

 

The spinner in some CV controllers can produce an IRQ, while the VDP produces a NMI. However the NMI connects directly to the Z80 and nothing else. So I cannot see how the controller problem would relate to any VDP timing issue.

[Tempest]

I fail to see the connection. Have you tried the ADAM with a regular 9928? Does the same issue with the controllers happen. All my CVs work with a single controller plugged in.

I can say that the ADAM did not do this with the original graphics chip in it. I never had to plug in two controllers to use it.

[matthew180]

I'm not sure about the how the CV reads the controllers, but I assume it would do so in the ISR? That would be the connection to the VDP.

 

The anomaly with Pole Position on the 99/4A was such that the more precise interval of the interrupt from the F18A vs the 9918A put the interrupt and the buggy code in lock-step and the game would appear to hang. However, with the varying nature of the 9918A's interrupt, it was enough to break the cycle and allow enough interrupts to get through that the game would appear to run normally.

 

If the CV has something similar in the way it handles when it reads the controllers, then the problem could be similar. The F18A generates the interrupt, which the Z80 is seeing, and it only resets the interrupt when the status is read, just like the original VDP. The only difference is *when* the interrupt is triggered, the time between interrupts, and how fast the VDP resets the interrupt once the status register is read.

 

But on the Z80, interrupts are edge-triggered, not level triggered (as in the 9900), so the time to reset the interrupt should not matter (but it is pretty much instant in the F18A, within 30ns of the status read, and before the host CPU is done with the status read cycle).

 

That only leaves the time between interrupts from the VDP. The funny thing is, reading the direction pad works fine, it is only the buttons that seem to be missed.

 

I would love to correct this problem, so if anyone has any suggestions or is familiar with how the CV reads the controllers, I'd love to have any suggestions.

Edited April 2, 2012 by matthew180

[opcode]

That is a weird bug. If it was only the right button, then I would see some connection, since the CV has a strobe line to select between directions + left button and keypad + right button.

How many games have you tried?

[opcode]

What I mean is that if you can read the directions then you can read the left button, since they are read in a single access.

[matthew180]

Ghostblasters, Donkey Kong, DKJ, Zaxxon, and Space Panic on CV, and Centipede and a few others on the ADAM via a 128-in-1 cart.

[matthew180]

Actually, I'll have to go back and confirm Donkey Kong. But with Ghostblasters and Centipede (which I tested last night), I could not start the games because they require a button press, however, selecting Centipede via the 128-in-1 requires the direction control and fire button, and that part worked fine. It was only once I got into the game's initial screen do I start having the problem (which happens instantly for dedicated cartridges). Having a second controller plugged in to the CV and ADAM fix the problem 100% of the time thus far.

[Tursi]

I only have one controller for my Coleco at all... I don't remember seeing this issue. I'll try it again.

[+OLD CS1]

So, do I read correctly that the F18A is programmable in TMS-9900 assembly?

 

Yes!

 

Sly bastard... do you know what you have done? Do you know what you have done?! You have created multi-processing, accelerated system for the TI. WHAT HAS SCIENCE DONE?!

 

Hey, I am not certain if there is a mention of DVI in this thread, but the next Indivision scan-doubler/flicker-fixer for the Amiga 1200 will have DVI output. Matt!

[rocky007]

So, do I read correctly that the F18A is programmable in TMS-9900 assembly?

 

Yes!

 

if you continue like this, your F18A will be a stand alone improved TI99 clone ! ( a Ti99 Direct-To-TV ? C64 Direct-to-TV )

[matthew180]

Well, not quite. I need a little more room in the FPGA, like a 500K device (the F18A uses a 250K FPGA to help keep costs down). But the biggest reason the F18A can't be a 99/4A SoC is that it does not have the physical I/O for the human stuff like a keyboard, removable storage, sound, and joysticks. It also needs an external RAM. I won't rule out making such a board in the future though. :-)

[matthew180]

Wow, a lot has changed with the F18A in the last few weeks. In between working on getting the boards made, I have been hard at work trying to firm up the feature list and get everything implemented. Probably the biggest addition was the 9900-based GPU which has allowed for a lot of great possibilities and of course added to the list of additional features. Before adding the GPU, the utilization of the FPGA was only around 38%. Now it is almost 90% with all the new stuff, which makes me a lot happier knowing I have filled the FPGA about as far as it will go, and very little is sitting there wasted.

 

I would like to get some public input on a few ideas I have been kicking around:

 

1. The GPU has a dedicated block of RAM that I call GPU-RAM or GRAM just to be really confusing. :-) Since this RAM is inside the FPGA, I have the ability to initialize it when the FPGA is being configured from the bit-stream at power-on. That means I could load it with some pre-written subroutines and such that might come in handy for anyone programming on a system with the F18A. The immediate ideas that come to mind are a line-drawing routine and a block move. But beyond that I'm coming up blank. So, if anyone has some ideas, I'd like to hear them.

 

2. Because of the GPU, the flash memory used to initialize the FPGA at power-on can be accessed for general purpose use once the FPGA is configured. Since the FPGA bit-stream is only 250K or so, and the flash memory is 1MB, there is about 600K sitting there. I was thinking about loading it up with all kinds of useful stuff and I would like some ideas. A few that I have come up with are:

 

* The patterns for all the font sets that sometimes99er has been collecting

* Sine and Cosine lookup tables

 

Heh, pretty short list. Again, the idea is easy, coming up with useful data to stuff in there, not so easy. Without being specific, these are some other possibilities:

 

* Common or interesting pattern data - maybe the best known graphics from popular games and such (remember this is not 99/4A specific)

* Audio / sound data, maybe like sound effects and such

* Useful subroutines - similar to #1 above, but there could be more routines in the flash that could be copied as-needed to RAM for execution

* Common data sets or lookup tables - similar to sine and cosine tables

 

Thoughts, ideas, suggestions, please let me know. Also, if anyone is interested in helping assemble these resources and getting them into their final binary form, please let me know.

 

I have also attached a recent image where I was testing some of the scrolling and fixed-tile features of the F18A. You can't see it in the still-photo, but parts of the master title screen on the 99/4A are scrolling. The "MMA=" text at the top is the result of a successful test reading from the flash memory. It is interesting what you can do with a static screen. I'll be compiling a short video of various tests as I complete them, and I'll post it as soon as I can.

Edited April 14, 2012 by matthew180

[Willsy]

Other things that would be cool:

• Ellipse/circle drawing
  
• Fill (though you could really do with a stack for that - see below).
  
• Real time clock (need registers to set/read the clock)
  

Regarding the stack, as we know, the 9900 doesn't have one; however, Cory Burr, the author of Win994A added a stack to the virtual 9900 CPU in the Win994A simulator.

 

He added a raft of 9900 instructions (using unused op-codes) to integrate the stack fully into the 9900 landscape, and he did a really great job. I don't like the mnemonics that he chose (though that's just my opinion) but the instructions are great! If only the real 9900 had these instructions! Anyway, you might want to take a look at the attached. The interesting stuff (for you) starts on page 9.

 

Mark

Enhancements.pdf

[matthew180]

Yup, I read that document a long time ago, and I was kicking around the idea of adding a CALL and RET instructions to the GPU. Both would be similar to BL and B *R11, but CALL would automatically push the current address, and RET would naturally pop an address for the return. I'm not sure about a PUSH and POP directly, or a generic stack, at least not this time around. The stack would also be fixed, probably something like 32 deep.