F18A

[matthew180]

I learned over the weekend that ceramic SMD capacitors cannot be reliably soldered using a soldering iron. It seems the ceramic material expands at a different rate than the circuit board and causes microscopic cracks in the crystalline structure of the ceramic. Apparently this will cause the parts to fail over time, and / or cause sporadic behavior.

 

I am glad I learned this now as I am gearing up to build the bulk run of boards, and it has caused me to modify my initial approach to board assembly. This is a small set back, but it should only take a week to get set up for the new process. I want to apologize for the delay, I am working on getting these done as fast as I can.

[ti99iuc]

Matthew, don't worry, i understand....

i will waiting your time

Thankyou for the upgrade info.

[intvnut]

I learned over the weekend that ceramic SMD capacitors cannot be reliably soldered using a soldering iron. It seems the ceramic material expands at a different rate than the circuit board and causes microscopic cracks in the crystalline structure of the ceramic. Apparently this will cause the parts to fail over time, and / or cause sporadic behavior.

 

I am glad I learned this now as I am gearing up to build the bulk run of boards, and it has caused me to modify my initial approach to board assembly. This is a small set back, but it should only take a week to get set up for the new process. I want to apologize for the delay, I am working on getting these done as fast as I can.

 

Interesting! Do you have a link with more information? I'd like to read up on this.

[apersson850]

Sorry for the off-topic, but the discussions above remind me about another discussion we had an evening, at the time (long ago) when I went to university, or Institute of technology, as it was called.

Someone said that if in the future, a computer could be designed with such capacity that it could simulate universe, and then whilst the simulation was running, someone drove a screwdriver through the circuits that represented you at that moment - would that then be cruel?

[apersson850]

Interesting! Do you have a link with more information? I'd like to read up on this.

He's right, and this is a well known issue for us in the electronic/electric business.

You'll find many links if you search the net. This one is the very first I came across.

[matthew180]

Yup, that Johanson Technology link is one I found, as well as here: http://www.zeph.com/pencil.html (see item 'F', and the caption to the image next to it).

 

I realize Zephyrtronics is trying to sell equipment, but they have awesome white papers and great information. I found all this out at a Ham Radio Swap Meet on Saturday (the only one that comes annually to my small town) and I went to buy a new soldering iron for the F18A build. I got talking to the vendor selling soldering tools and found out he is also a soldering instructor. I had an F18A with me and we talked for about an hour. At some point he mentioned that you cannot solder the ceramics with an iron. When I got home, I started searching around and found information that confirms his statement.

 

Up until that point I was planning on hand soldering the boards, but now I have switched to a solder paste / oven reflow process, so I have had to buy a lot of extra equipment that I am now waiting for to arrive. Hopefully the delay in getting started will be made up for in the more rapid assembly - if I don't !@#$% them up that is...

[microprocessor]

Matthew,

 

Would you consider an F38 project after you're done this one?

We discussed it a little on the Yahoo group, but it seems you're

not a member there: http://tech.groups.y...m/group/TI994A/

(shameless plug).

 

I submit that emulating a V9938 with VGA output is actually more

critical at this point in time than a 9918.

Would be nice to have a V9938/58 replacement, however:

 

The point is that V9938 is FAR more difficult to emulate that TMS.

- ScanLine interrupts

- Scroll Registers

- Weird sprite color issues ( the infamous OR color bit)

- Strange Hw colored tile mode in 512x212x4 modes.

- Vdp command engine speed, that is TOTALLY unknown. Sometimes is difficult to undertand why a blitter command run at specific speed.

(Speed is influenced by, (but in unclear way), the different conditions: type of command, active or blank area, sprites enabled or not...)

- There are some complex things, mainly due to the requirement of the compatibility with TMS

- Some strange things. the v9938 screen adjust register cannot be written if there is a blitter command in progress, if you do, you will loose random pixels processed by the command.

- On TMS polling status register can result something to get the interrupt bit cleared. if the original TMS is reaching blank area, and you read status register by polling, there is a chance you can get the interrupt bit always 0 and the interrupt does not happen. On V9938 this bug is corrected. On blank area even polling the status reg, you always get it active.

 

I think mattew is reluctant to create a v9938 drop in simply because it's too hard...

[microprocessor]

 

I can't figure out what that guy is doing with 32K of VRAM. He can bank-switch it out from under the 9918A, but he would have to have most of the data set up the same in both banks, otherwise your display would go crazy when you switched. I can't find any real details on his site about how he is using the 32K VRAM.

 

If / when I do more than the initial 16K, I will most likely do it the 9938-way.

The advantages?

think about DIRECT ACCESS to VRAM instead of the CRAPPY mode the TMS use. While a bank is not used by vdp the cpu can write @ full speed. Of course F18A does not have this problem. But think about the limited design. As a MSX hw freak i can tell you that a z80 random read operation can be done in about 7 clks in its ram. the same in VRAM cost about a factor of 7-10 times. Partly due to the slowness of the z80 instructions used to comunicate with vdp, but more for the TMS issues.

 

The 6809 chip is a very fast 8 bit. hooking up to the slow protocol needed to be used with TMS is a huge bottleneck. That's probably the reason the guy choose a double-buffered approach.

[microprocessor]

You can have 32 Sprites on a line if you want with the F18A. It is set with a jumper. However, *if* the *software* (game etc) is looking for 5 or more Sprites on a line then you will still see flicker, as the *game* will be moving the Sprites on and off the screen very fast (which makes them flicker) to try to get around the 4 on a line restriction. There is nothing the f18 can do about this: it can only obey the commands given to it by the host software.

not true. F18A show 32 sprites. If the software rotate SAT, there will be no dropped sprites that disappear. Even if rotated ALL SPRITES are correcly showed every frame

It's the same if you were rotating only 4 sprites on the original TMS. you will notice nothing. (Maybe only a priority sprite swap when the plane 0 became 32 at the next frame because of rotation). But it's not flickering.

Edited March 25, 2012 by microprocessor

[Willsy]

That assumes you're using a rotating technique. You might not be.

[microprocessor]

That assumes you're using a rotating technique. You might not be.

90% of sw uses it, almost in msx or CV worlds

[Willsy]

Okay, so 10% doesn't. Therefore it will flicker in the same way as the original video chip.

 

Again: if your code changes a sprites row or column, then the sprite moves. The under-lying hardware is irrelevant.

[matthew180]

Update:

 

Parts are in, reflow (read: toaster) oven is in, and I'm currently working on a reflow profile that matches my solder paste. With any luck I hope to be making boards this weekend.

 

Also, while waiting for the parts and such to come in, I managed to implement a 9900 core. So, the F18A will have a GPU based on the 9900 machine code, provided I can get it tested well enough to consider it "production". So much to do! Most of the 9900 instructions are implemented, however there are some differences:

 

* The registers (R0 - R15) are *real* (internal to the GPU instead of memory-based), meaning no workspace pointer and only one set of registers.

 

* There are currently no interrupts, but that *might* change.

 

* No CRU I/O

 

* These instructions are not implemented: BLWP, X, XOP, LDCR, STCR, SBO, SBZ, TB, STWP, LWPI, LIMI, RSET, CKOF, CKON, LREX

 

* The GPU has 2K of private RAM that starts at >4000 (>0000 to >3FFF is the normal 16K of VRAM)

 

* The GPU can be triggered or run continuously

 

Currently instructions are taking between 100ns and 200ns (10 and 20 F18A clock cycles) to execute, so about an average of 10 instructions per microsecond. To compare this to the real 9900, in the data manual there is an example of a MOVB instruction with both source and destination operands as workspace registers, something like:

 

MOVB R1,R2

 

That instruction is calculated to take 4.662us without wait states. The F18A 9900 GPU will do that in about 140ns, or about 33 times faster.

 

[Willsy]

That's 7.5 MIPS, is it not? Holy cow! :-o :-o :-o :thumbsup: :thumbsup: :thumbsup:

[matthew180]

Well, I was just reading about MIPS and it is very hard to determine a CPU's performance based on the numbers you see. Based on the chart on wikipedia, 7.0 MIPS puts my GPU at 7x faster than a 68000 (1 MIPS), and between the 68020 (4 MIPS) and the 68030 (11 MIPS). The 386DX is reported at 11.4 MIPS. Of course these CPU's are all running between 20MHz and 40MHz, so I'm not sure how they can execute instructions faster than they could be fetched from memory... I'm sure all of those CPUs are seriously pipelined and using multiple execution units (ALUs), L1 and L2 cache, etc.

 

So yes, the F18A GPU is about 7 MIPS, but it is hard to say what that really means in terms of anything really. We'll just have to see what people do with it. :-)

[GroovyBee]

So yes, the F18A GPU is about 7 MIPS, but it is hard to say what that really means in terms of anything really. We'll just have to see what people do with it. :-)

 

Would it be possible to implement a small instruction cache on the GPU? Might come in handy for handling "tight" loops. I'm not sure what the definition of "tight" would be on the Ti though. I don't know enough about the architecture.

[Willsy]

As I understand it, the gpu doesn't go out to the bus for its instructions - the ram is inside the FPGA so it kind of is cached, in a very basic way. One method might be to decode instructions while the previous instruction is executing - but we're getting carried away now!

[matthew180]

The F18A RAM is all internal to the FPGA and can be accessed every clock cycle. It is all dual-port RAM too, so two circuits can be accessing the memory at the same time.

 

Instruction "decode" takes 1 clock cycle (10ns), so prefetching and decoding the next instruction is really only a very small gain. The two places that are eating most of the time are the 8-bit memory instead of a 16-bit memory, and the various memory access modes, i.e. symbolic, indexed, etc. The biggest optimization would be to make the VRAM 32-bits wide, in which case I could pull an instruction and the following word in a single cycle. That complicates the video circuits though, and would require a massive over-haul to the core of the VDP. That's not going to happen this time around. Maybe in the future...

 

I have been thinking about a LOOP opcode that would repeat the next (or previous) instruction multiple times. That would make block moves much faster. We'll see though, I already have a lot of loose ends to tie up and boards to get assembled.

 

[+retroclouds]

wow! That is neat, a 9900 clone hidden in the F18A. Is that part of the secret plan on bringing the 9900 to all the Colecovisions and MSX'es out there?

Seriously, I think that is very cool feature and I'm looking forward seeing how this all further develops :thumbsup:

Edited March 27, 2012 by retroclouds

[matthew180]

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. However, I was not happy with the license on most of them, plus I wanted to do a CPU in HDL anyway, and a 9900 core does not exist.

 

I will be very interested to see what people do with it, and holy crap do I have a lot of examples and documentation to write now!

[Cory]

So I'm going to expose my ignorance and ask a question. Can you explain what you mean by GPU in the context of this project? I'm not 100% sure I understand what it means to add a GPU to the FA18.

 

I believe a GPU offloads graphics processing from the CPU and allows you to "process" graphics related instructions in parallel with CPU instructions. Perhaps "in parallel" is the wrong term. Maybe independant is a better word. Am I on the right page here? If so, I'm assuming that adding a GPU would allow us to perform some interesting functions like horizontal scrolling or multi-layer scrolling without requiring direct hardware support.

 

I hope I'm warm, because I'm getting pretty excited with possibilities now that I'm thinking about it.

[matthew180]

GPU probably means a lot of things to a lot of people, but in this context I'm referring to a "programmable processor" inside the F18A that can run its own code, and in this case I decided to implement a 9900 machine-instruction compatible CPU as the "GPU". I call it a "graphics processing unit" because it is inside the VDP (a.k.a. graphics chip), and also to be able to call it something to differentiate it from the host system's CPU. In this case, the GPU does not specifically have "graphic" oriented commands like you might find in a modern graphics card.

 

The GPU's "memory space" is the VRAM, so it can access it directly, as well as an additional 2K of private RAM. This RAM has nothing to do with the 64K address space of the 9900 CPU in the 99/4A computer. The F18A *cannot* directly access the main host system's RAM or I/O ports.

 

As for scrolling, the F18A has hardware scroll registers for pixel-level scrolling in both horizontal and vertical directions, so you don't need to do that with the GPU. The host system's CPU can now easily handle scrolling since it only requires updating a few VDP registers.

 

Since the GPU has its own program code, it is truly a co-processor and runs independent from, and in parallel to, the host system's CPU. Also keep in mind that the host system is not always a 99/4A, but might be a ColecoVision, MSX, Tommy Tutor, etc.

 

I hope you, and everyone else are exited! I know I am, and I can't wait to see what people do with the F18A!

Edited March 28, 2012 by matthew180

[JonnyBritish]

So its more like a co processor so for example you could have it running your AI code to determine the next move for example

Edited March 28, 2012 by JonnyBritish

[matthew180]

Yes. The GPU is inside the VDP, and like the original 9918A, can not access the rest of the host system. The F18A cannot do anything the original 9918A could not do as far as system access goes. However, there is plenty you can do from inside the VDP, and you have the entire 16K of VRAM as a shared memory between the host CPU and the GPU. The GPU could run a complete game, for example, and simply rely on the host system to update certain VRAM memory locations with player input information, and play sounds on queue from from the GPU. It is entirely up to you.

 

Some other ideas that come quickly to mind are:

 

* high speed line drawing

* high precision collision detection

* sprite reuse (for example, you could use a single sprite for multiple bullets)

* graphic effects

 

Let you imagination run.

[microprocessor]

Okay, so 10% doesn't. Therefore it will flicker in the same way as the original video chip.

 

Again: if your code changes a sprites row or column, then the sprite moves. The under-lying hardware is irrelevant.

It's always possible to change the sw to take advantage of F18A