54 replies to this topic

[hloberg]

marc.hull, on Tue Jan 31, 2012 4:17 PM, said:

Lee Stewart, on Tue Jan 31, 2012 3:53 PM, said:

hloberg, on Tue Jan 31, 2012 2:56 PM, said:

Wherefore GPL? One of those eternal questions that may never be answered.
<Been looking through the forum and haven't found these answers.>
Now for some dumb (and maybe obvious) questions. Is GPL processed by the VDP and not the CPU? Is GRAM and GROM memory accessed by the VDP only? How can you program GPL from an emulator and what tools you use?

Suggestion Rich, maybe a tutorial on GPL would help people appreciate it's power. As you point out in a previous post it can use a lot less coding than assembler and is almost as fast.

Uh, oh! You're gonna catch it for that. You probably have not checked out the "GPL HOW 2 SERIES" on this forum in the TI-99/4A Development Resurces at http://www.atariage....ment-resources/, have you?

...lee

Ya know if you want to take a jab at Rich (applies to everyone) then have the balls to come out like a man and take a jab at him. Shove your smileys and your sarcasm and just say what's on your mind. If you can't do that then STFU and sit back down in your corner. This is gutless BS.

No jab intended on Rich's part.
I respect the work he's done and would like to hear MORE about GPL.
'Wherefore GPL' refers to the debate that has been going back and forth in the TI community forever concerning GPL. I can remember debating it way back in the 80s with some friends of mine to no end.
As for the rest of the post that was an actual question so I could start to learn MORE about GPL and a full tutorial from 'the man' himself WOULD be neat. I must have over looked the post 'GPL how to series' when I was looking for stuff on GPL.
Remember guys, this is just a hobby so be cool.

[hloberg]

Lee Stewart, on Tue Jan 31, 2012 3:53 PM, said:

hloberg, on Tue Jan 31, 2012 2:56 PM, said:

Wherefore GPL? One of those eternal questions that may never be answered.
<Been looking through the forum and haven't found these answers.>
Now for some dumb (and maybe obvious) questions. Is GPL processed by the VDP and not the CPU? Is GRAM and GROM memory accessed by the VDP only? How can you program GPL from an emulator and what tools you use?

Suggestion Rich, maybe a tutorial on GPL would help people appreciate it's power. As you point out in a previous post it can use a lot less coding than assembler and is almost as fast.

Uh, oh! You're gonna catch it for that. You probably have not checked out the "GPL HOW 2 SERIES" on this forum in the TI-99/4A Development Resurces at http://www.atariage....ment-resources/, have you?

...lee

Thanks, I must had my search criteria wrong. I'll watch the videos soon.
Again, no disrespect to Rich.

[hloberg]

jchase1970, on Tue Jan 31, 2012 5:29 PM, said:

This forum keeps taking little dives towards the yahoo group mentality. This is a programming forum for people to learn and experience the Ti99 in. Using BASIC, XB, GPL, FORTH, ASSEMBLY, or anything else. We need no, "MY WAY IS THE BEST WAY" or "YOU WAY IS TERRIBLE" flame wars on here.

We want a friendly open enviroment that the TI has NEVER had to expand the quantity and quality of the programs available for the TI. A place where beginners and experienced can come and share and learn and teach the ins and outs of the TI. It's a very unique machine that has quarks that make it so much fun to learn about and try to over come.

I agree and if anyone took my comments as a dig, i apologize. They were not meant to be such.

[Lee Stewart]

hloberg, on Tue Jan 31, 2012 6:26 PM, said:

jchase1970, on Tue Jan 31, 2012 5:29 PM, said:

This forum keeps taking little dives towards the yahoo group mentality. This is a programming forum for people to learn and experience the Ti99 in. Using BASIC, XB, GPL, FORTH, ASSEMBLY, or anything else. We need no, "MY WAY IS THE BEST WAY" or "YOU WAY IS TERRIBLE" flame wars on here.

We want a friendly open enviroment that the TI has NEVER had to expand the quantity and quality of the programs available for the TI. A place where beginners and experienced can come and share and learn and teach the ins and outs of the TI. It's a very unique machine that has quarks that make it so much fun to learn about and try to over come.

I agree and if anyone took my comments as a dig, i apologize. They were not meant to be such.

...as do I. My elaborate "oops" was, perhaps, ill-advised, but said in jest---certainly not intended as a dig. The remainder was information I thought would be useful, which would have been pointed out soon enough by Rich. I have viewed some of those videos and was duly impressed.

...lee

[marc.hull]

hloberg, on Tue Jan 31, 2012 5:41 PM, said:

marc.hull, on Tue Jan 31, 2012 4:17 PM, said:

Lee Stewart, on Tue Jan 31, 2012 3:53 PM, said:

hloberg, on Tue Jan 31, 2012 2:56 PM, said:

Wherefore GPL? One of those eternal questions that may never be answered.
<Been looking through the forum and haven't found these answers.>
Now for some dumb (and maybe obvious) questions. Is GPL processed by the VDP and not the CPU? Is GRAM and GROM memory accessed by the VDP only? How can you program GPL from an emulator and what tools you use?

Suggestion Rich, maybe a tutorial on GPL would help people appreciate it's power. As you point out in a previous post it can use a lot less coding than assembler and is almost as fast.

Uh, oh! You're gonna catch it for that. You probably have not checked out the "GPL HOW 2 SERIES" on this forum in the TI-99/4A Development Resurces at http://www.atariage....ment-resources/, have you?

...lee

Ya know if you want to take a jab at Rich (applies to everyone) then have the balls to come out like a man and take a jab at him. Shove your smileys and your sarcasm and just say what's on your mind. If you can't do that then STFU and sit back down in your corner. This is gutless BS.

No jab intended on Rich's part.
I respect the work he's done and would like to hear MORE about GPL.
'Wherefore GPL' refers to the debate that has been going back and forth in the TI community forever concerning GPL. I can remember debating it way back in the 80s with some friends of mine to no end.
As for the rest of the post that was an actual question so I could start to learn MORE about GPL and a full tutorial from 'the man' himself WOULD be neat. I must have over looked the post 'GPL how to series' when I was looking for stuff on GPL.
Remember guys, this is just a hobby so be cool.

Your being a jackass and it's really transparent,

[matthew180]

hloberg, on Tue Jan 31, 2012 3:07 PM, said:

Now for some dumb (and maybe obvious) questions. Is GPL processed by the VDP and not the CPU?

No. The VDP does not "process" any user code or anything like that. It is a dedicated video "processor" in that it generates the video display without any CPU or system intervention. The VDP has its own RAM that is uses to generate the video, and the host system can access the "VRAM" (video RAM) via the VDP's 8-bit interface. Since the stock 99/4A didn't have any RAM except the 16K of VRAM, and 256 *bytes* of 16-bit CPU RAM, BASIC (and XB without the expansion) have to use the VRAM exclusively for everything, i.e. program storage, variable storage, etc.

Accessing the VRAM has to be done by going "through" the VDP, so that means 1 byte at a time, and it triggers the 99/4A's wait state generator. Also, there are other nuances that make certain kinds of access even slower, i.e. when you have to set up the read or write address of where you want to access the VRAM. All this makes using VRAM slower than what a computer system typically has for its main memory, i.e. RAM and ROM directly connected to the address and data busses.

This is just a very brief summary, so do some searching around and you can find a ton of detailed info on this.

hloberg, on Tue Jan 31, 2012 3:07 PM, said:

Is GRAM and GROM memory accessed by the VDP only?

No. Actually, the VDP can't access any GRAM or GROM. The VDP can only access its dedicated 16K of dynamic RAM, a.k.a. VRAM, and the VDP does not "execute" any code.

hloberg, on Tue Jan 31, 2012 3:07 PM, said:

How can you program GPL from an emulator and what tools you use?

Rich can help you out in this area, he has a good passion for GPL and a tutorial thread on this forum.

hloberg, on Tue Jan 31, 2012 3:07 PM, said:

Just read Willsy comments. The GPL processor is virtual? i was assuming it was more like the graphics language used in high end VDPs of today. It sounds more like JAVA.

Technially JAVA sounds more like GPL, since GPL existed before JAVA was even a spark in anyone's imagination. GPL, I believe, stands for Graphics Programming Language, however it is nothing like anything that would run on a modern PC's graphic card's GPU. There is a GPL interpreter in the console ROM which executes GPL programs. This is very similar to P-Code of the same era, but it is suspected that GPL was primarily used as a way for TI to control software on the 99/4A. Also, since GPL is a "byte code" language (its opcodes are a single byte), it can be stored in, and executed from, GROM or GRAM (which were also a way TI controlled software on the 99/4A.)

Edited by matthew180, Tue Jan 31, 2012 10:02 PM.

[hloberg]

Thanks Matthew,
I have been under the misconception that GPL was actually tied to the VDP.
You know, a better analogy might be GPL as a type of application layer. You talk to it, it talks to the hardware.
If the hardware was fast enough, it would sped up programming a lot (like Rich pointed out).
Not too different from the programming layers in Windows now.
Actually in the Miniframe/Mainframe world of that era you rarely programmed at the ML level unless you were one of the company engineers. There was always a programming layer for the client to use above the ML layer. Sometimes it was compiled and sometimes it was interpreted. I programmed on various mainframes/miniframes in COBOL and other languages back then and never once touched the ML.
TI was just doing what they had done with there bigger machines on a smaller machine.
Of course, this is all theory.

Edited by hloberg, Tue Jan 31, 2012 11:31 PM.

[Willsy]

hloberg, on Tue Jan 31, 2012 11:28 PM, said:

Thanks Matthew,
I have been under the misconception that GPL was actually tied to the VDP.
You know, a better analogy might be GPL as a type of application layer. You talk to it, it talks to the hardware.
If the hardware was fast enough, it would sped up programming a lot (like Rich pointed out).
Not too different from the programming layers in Windows now.
Actually in the Miniframe/Mainframe world of that era you rarely programmed at the ML level unless you were one of the company engineers. There was always a programming layer for the client to use above the ML layer. Sometimes it was compiled and sometimes it was interpreted. I programmed on various mainframes/miniframes in COBOL and other languages back then and never once touched the ML.
TI was just doing what they had done with there bigger machines on a smaller machine.
Of course, this is all theory.

I agree. The 4A 'feels' like a mini-computer in terms of it's programming environment, the way the file system works, DSRs etc etc - much more sophisticated than any of its peers. Only the Amiga came close (well, surpassed, I guess) - for example, the Amiga introduced AutoConfig - a similar system to DSRs whereby add-on hardware contained it's own housekeeping code and libraries to be executed by the 68000.

Getting back to GPL, the word is that the GPL byte-code was to be executed by a custom GPL processor - hence the reason that the instruction set is set out very much like a real chip. In order to continue developing the computer before silicon was ready a GPL interpreter/simulator was developed. The silicon never saw the light of day, and we're left with the GPL interpreter that we have today.

There's another thread on here where I re-posted an interview that Matthew did with Carl Guttag, the designer of the TMS9995. He recounts some of these stories.

[Tempest]

Ok this is everyone's one and only warning. Stop the attacks, stop the name calling, and stop shouting people down or I will take action. You won't like me when I'm angry...

[RXB]

matthew180, on Tue Jan 31, 2012 9:55 PM, said:

hloberg, on Tue Jan 31, 2012 3:07 PM, said:

Now for some dumb (and maybe obvious) questions. Is GPL processed by the VDP and not the CPU?

No. The VDP does not "process" any user code or anything like that. It is a dedicated video "processor" in that it generates the video display without any CPU or system intervention. The VDP has its own RAM that is uses to generate the video, and the host system can access the "VRAM" (video RAM) via the VDP's 8-bit interface. Since the stock 99/4A didn't have any RAM except the 16K of VRAM, and 256 *bytes* of 16-bit CPU RAM, BASIC (and XB without the expansion) have to use the VRAM exclusively for everything, i.e. program storage, variable storage, etc.

Accessing the VRAM has to be done by going "through" the VDP, so that means 1 byte at a time, and it triggers the 99/4A's wait state generator. Also, there are other nuances that make certain kinds of access even slower, i.e. when you have to set up the read or write address of where you want to access the VRAM. All this makes using VRAM slower than what a computer system typically has for its main memory, i.e. RAM and ROM directly connected to the address and data busses.

This is just a very brief summary, so do some searching around and you can find a ton of detailed info on this.

hloberg, on Tue Jan 31, 2012 3:07 PM, said:

Is GRAM and GROM memory accessed by the VDP only?

No. Actually, the VDP can't access any GRAM or GROM. The VDP can only access its dedicated 16K of dynamic RAM, a.k.a. VRAM, and the VDP does not "execute" any code.

hloberg, on Tue Jan 31, 2012 3:07 PM, said:

How can you program GPL from an emulator and what tools you use?

Rich can help you out in this area, he has a good passion for GPL and a tutorial thread on this forum.

hloberg, on Tue Jan 31, 2012 3:07 PM, said:

Just read Willsy comments. The GPL processor is virtual? i was assuming it was more like the graphics language used in high end VDPs of today. It sounds more like JAVA.

Technially JAVA sounds more like GPL, since GPL existed before JAVA was even a spark in anyone's imagination. GPL, I believe, stands for Graphics Programming Language, however it is nothing like anything that would run on a modern PC's graphic card's GPU. There is a GPL interpreter in the console ROM which executes GPL programs. This is very similar to P-Code of the same era, but it is suspected that GPL was primarily used as a way for TI to control software on the 99/4A. Also, since GPL is a "byte code" language (its opcodes are a single byte), it can be stored in, and executed from, GROM or GRAM (which were also a way TI controlled software on the 99/4A.)

Thank you. You said what I was getting at very eloquently and to the point. I do view Graphic Programming Language as being a pre cursor to JAVA. GPL is not fast but compact and easy to use.
Secondly I was pointing out that VDP is the bottleneck as the entire TI uses it and if you wanted to find the real bottleneck then VDP affects all languages equally and not for the good of speed. i.e. 1 byte at a time. (with a delay loop also)
Please go back to the original post and see that he asked why TI XB and BASIC is slower then other machines Basic. I was aswering his question as I used many of the other Basics.
(If the VDP in the TI was equal in speed to other machines like the PCjr or Quickbasic or Timex Sinclair then TI Basic or XB would not look so slow. Just consider the statement)

Edited by RXB, Wed Feb 1, 2012 11:58 AM.

[hloberg]

Willsy, on Wed Feb 1, 2012 1:38 AM, said:

hloberg, on Tue Jan 31, 2012 11:28 PM, said:

Thanks Matthew,
I have been under the misconception that GPL was actually tied to the VDP.
You know, a better analogy might be GPL as a type of application layer. You talk to it, it talks to the hardware.
If the hardware was fast enough, it would sped up programming a lot (like Rich pointed out).
Not too different from the programming layers in Windows now.
Actually in the Miniframe/Mainframe world of that era you rarely programmed at the ML level unless you were one of the company engineers. There was always a programming layer for the client to use above the ML layer. Sometimes it was compiled and sometimes it was interpreted. I programmed on various mainframes/miniframes in COBOL and other languages back then and never once touched the ML.
TI was just doing what they had done with there bigger machines on a smaller machine.
Of course, this is all theory.

I agree. The 4A 'feels' like a mini-computer in terms of it's programming environment, the way the file system works, DSRs etc etc - much more sophisticated than any of its peers. Only the Amiga came close (well, surpassed, I guess) - for example, the Amiga introduced AutoConfig - a similar system to DSRs whereby add-on hardware contained it's own housekeeping code and libraries to be executed by the 68000.

Getting back to GPL, the word is that the GPL byte-code was to be executed by a custom GPL processor - hence the reason that the instruction set is set out very much like a real chip. In order to continue developing the computer before silicon was ready a GPL interpreter/simulator was developed. The silicon never saw the light of day, and we're left with the GPL interpreter that we have today.

There's another thread on here where I re-posted an interview that Matthew did with Carl Guttag, the designer of the TMS9995. He recounts some of these stories.

Read your thread with Carl Guttag.
What a great discussion. I knew some of the stuff but didn't know others. really cool.
It does explain a lot about GPL. IF it had a dedicated processor it would have been a great programming layer above ML. Even as it was it was OK for things that didn't require real high speed (such as game graphics).

From his discussion I can see 'culture wise' where the TI99 went wrong. On most of the machines of that era, they built their machines in small groups with an off the shelf CPU (6502/6809) that gave them a set of limitations to work with. They knew where they were going, what their limits where and what they had to do to get their. From what Carl said it looks like TI, on the other hand, was building the CPU, VDP, OS, GPL and all the other parts in different departments at TI all at once (more or less) with changing specs and requirements and then trying to glue the whole thing together at the end. It must have been 'heck' on the programmers. I remember when I had to program where the goals where constantly shifting it was miserable. As Carl said: “the 99/4 had the best bag of parts but they were put together wrong.”
I disagree, even with all the challenges, I think the people at TI did a really good job assembling their 'bag of parts'. It gives credit to the people involved.

Edited by hloberg, Wed Feb 1, 2012 12:01 PM.

[matthew180]

RXB, on Wed Feb 1, 2012 11:35 AM, said:

(If the VDP in the TI was equal in speed to other machines like the PCjr or Quickbasic or Timex Sinclair then TI Basic or XB would not look so slow. Just consider the statement)

Well, that part is what I don't agree with. The MSX1 systems use the 9918A and their BASIC is very fast, *and* you get full access to the VDP as well. Also, accessing VRAM through the 9918A is not any slower than the 32K RAM expansion *once you set up the address*. Unfortunately GPL sets up the VDP address for *every* access, so it incurrs a penalty for every VRAM memory access, but you can avoid that when writing a program in assembly.

[OLD CS1]

The idea of a dedicated GPL processor is interesting. How would that have interfaced with the 9900 or the original CPU meant for the 99/4? Some kind of processor trap?

[matthew180]

No one really knows, it is all speculation. I have read that the 99/4A was supposed to have a GPL processor and the 99/4A was only ever supposed to run GPL. I have also read that the 99/4A was supposed to get the 9995 CPU, but it was not ready so the engineers shoe-horned in the 9900. Maybe someone knows an actual 99/4A engineer from the "home computer" division who can answer that question...

[hloberg]

Question:
If GPL is a virtual machine then how is it able to access memory beyond 64k of the 9900?
Does GROM and GRAM chips themselves do a type of bank switching or is there more circuitry that does the bank switching for the GRAM and GROM? (I have heard of GPL referred to block 1, 2 etc..)
Also can anything other than GPL code be stored in GRAM?
That's it for questions. I will be off for a while as I have a big project coming up and this retro-computing is like 'crack cocaine' to me and I need to focus.

[hloberg]

Oh, and to close off my part of this thread I'm starting to agree with Tursi that there isn't much that could be done to speed up XB due to the limitations of the machine. At best a good parity might be achieved with some of the machines of the time, after a lot of rewriting, but that's about all.

[RXB]

hloberg, on Wed Feb 1, 2012 4:20 PM, said:

Question:
If GPL is a virtual machine then how is it able to access memory beyond 64k of the 9900?
Does GROM and GRAM chips themselves do a type of bank switching or is there more circuitry that does the bank switching for the GRAM and GROM? (I have heard of GPL referred to block 1, 2 etc..)
Also can anything other than GPL code be stored in GRAM?
That's it for questions. I will be off for a while as I have a big project coming up and this retro-computing is like 'crack cocaine' to me and I need to focus.

My RXB has several Assembly routines imbedded into the GRAM.
As for the bank switching the TI was designed in the console alone to access 640 K of GROM or GRAM in 40 K pages. So this shows where they were headed.
So you could write 600 K of Assembly and the GPL would load and link it 40 K of pages at a time, but then the TI only has 32 K of RAM.
I suppose you could also count the Cart space for 40 from >2000 to >3FFF and from >6000 to >FFFF

Edited by RXB, Wed Feb 1, 2012 4:55 PM.

[Ksarul]

The TI-designed 128K Super RAM card included RAM in the >4000 space as well, so you could get up to 48K without banking anything out. Anything that needed a DSR would bank out that 8K, but it was still an available option space. I have one of these.

[moulinaie]

Willsy, on Wed Feb 1, 2012 1:38 AM, said:

Getting back to GPL, the word is that the GPL byte-code was to be executed by a custom GPL processor - hence the reason that the instruction set is set out very much like a real chip. In order to continue developing the computer before silicon was ready a GPL interpreter/simulator was developed. The silicon never saw the light of day, and we're left with the GPL interpreter that we have today.

Could anyone build this GLP "processor" and install it into the TI-99 ???
As the project of a FPGA to replace the VDP system.

Guillaume.

[OLD CS1]

moulinaie, on Thu Feb 2, 2012 3:17 AM, said:

Willsy, on Wed Feb 1, 2012 1:38 AM, said:

Getting back to GPL, the word is that the GPL byte-code was to be executed by a custom GPL processor - hence the reason that the instruction set is set out very much like a real chip. In order to continue developing the computer before silicon was ready a GPL interpreter/simulator was developed. The silicon never saw the light of day, and we're left with the GPL interpreter that we have today.

Could anyone build this GLP "processor" and install it into the TI-99 ???
As the project of a FPGA to replace the VDP system.

Guillaume.

That exact thought it was spurred my question about the interface. I assumed the system design would have to have some kind of MMU to determine which processor handled which memory space, be hand-fed instructions by the processor (which would increase execution time,) have some kind of CPU trap to throw the instructions to the GPL processor (similar to a math co-pro,) or the GPL processor might sit in front of the CPU and either hand it decoded GPL instructions or hand off non-GPL opcodes to the CPU.

In any case, I do not see our 99s getting such a unit as an add-on. Now, as a full CPU replacement, perhaps. The FPGA (or whatever) would have to determine the difference between GPL and 9900 instructions, or perhaps intercept calls to the GPL interpreter within the hardware. Ah, but maybe as an add-on a custom-made GPL processor could intercept calls to the ROM-based GPL interpreter by catching addressing or snooping the bus and man-handling the 9900. For that matter, such a device could actually sit on or under the real 9900 so it would not have to emulate the CPU. Tricky, but neat to contemplate.

Whatever might work, you can absolutely count on me not to be involved in such a project. I am just an idea guy, and most of them are not all that good to begin with.

[jchase1970]

Ksarul, on Wed Feb 1, 2012 10:27 PM, said:

The TI-designed 128K Super RAM card included RAM in the >4000 space as well, so you could get up to 48K without banking anything out. Anything that needed a DSR would bank out that 8K, but it was still an available option space. I have one of these.

I've thought about this before, so now is a good time to ask.....
If you can have 48k with out banking, does that mean you can do 48k bank switching and if so can you do that as a sidecart like the couple that do exist? Seems like if sidecarts could have access 48k at once then someone would be able to make anygame that the MSX series runs. They all just need more memory cause they all run in full bitmap mode.

48k blocks over 8k blocks would really be alot room and easier to program for.

[matthew180]

hloberg, on Wed Feb 1, 2012 4:20 PM, said:

Question:
If GPL is a virtual machine then how is it able to access memory beyond 64k of the 9900?
Does GROM and GRAM chips themselves do a type of bank switching or is there more circuitry that does the bank switching for the GRAM and GROM? (I have heard of GPL referred to block 1, 2 etc..)

GROM and GRAM are mapped in to the 9900 address spaces as "ports". "Port Mapped" means, when you read or write to a specific memory address (usually 1 address for reading, and 1 address for writing), you are accessing the device. The addresses where specific devices are mapped is decided by how the system is designed and built. The VDP is memory mapped, as is the sound chip, and of course GROM and GRAM (and I'm sure other things I'm forgetting.)

The 99/4A has enough ports reserved for something like 256 GROM devices, and since each GROM is 6K (I think), that is about 1.5MB of possible "memory". I'm sure others will correct my numbers, but that's basics of it. Personally I don't consider this as very useful memory since you can't execute assembly from it, and compared to RAM or ROM, it is slow. Also, TI was the only company in the world who made GROM chips, and they did not release official datasheets for them, so it was really just another way for them to maintain software control on the 99/4A. TI also made a decision to have the main system GROM chips in the 99/4A ignore a good part of the port selection, so the possible GROM count went from 256 to something like 16. Again, I can't remember exactly.

In case you are wondering how you get 6K of memory at a single address, a GROM works by keeping an internal address counter that auto-increments after a read or write to the GROM. This seemed to be a very common theme at TI since that is also how the 9918A (the VDP) works. So, you first have to "set up" the address in the GROM by sending it two bytes (the lower and upper part of the address), then you can read / write (in the case of GRAM, which TI never actully made) data. This works fine for GPL since it is a byte-code language, but does not work for 9900 binary (i.e. assembly) programs.

hloberg, on Wed Feb 1, 2012 4:20 PM, said:

Also can anything other than GPL code be stored in GRAM?

Sound data is commonly stored in GROM, as well as tile pattern information for the VDP, etc. Basically any "data" you need to store could be in a GROM. You could even store 9900 binary code in GROM, but you would have to copy it to CPU RAM before you could execute it. The main problem is availability. You can't by a GROM that you can "burn" like an EPROM, and for all intents and purposes GRAM does not exist. Yes, yes, there are devices out there like the GRAM-Kracker and such, but they are rare and not commonly available. The 99/4A certainly did not have any user accessible way to work with GROM or GPL, or any GRAM on the mainboard for developers to use.

Edited by matthew180, Thu Feb 2, 2012 8:20 AM.

[matthew180]

moulinaie, on Thu Feb 2, 2012 3:17 AM, said:

Willsy, on Wed Feb 1, 2012 1:38 AM, said:

Getting back to GPL, the word is that the GPL byte-code was to be executed by a custom GPL processor - hence the reason that the instruction set is set out very much like a real chip. In order to continue developing the computer before silicon was ready a GPL interpreter/simulator was developed. The silicon never saw the light of day, and we're left with the GPL interpreter that we have today.

Could anyone build this GLP "processor" and install it into the TI-99 ???
As the project of a FPGA to replace the VDP system.

Guillaume.

Yes.

The problem is motivation. There is no market to justify the massive effort, so whoever was working on it would have to be passionate about GPL... Rich... When is your FPGA GPL processor going to be released?

Seriously though, that would be a *HUGE* amout of work for almost no benefit. One of the biggest problems with GPL is that, to this day, it is a closed proprietary language. Just like the GROM, TI never released information about it. The main documentation available is from a reverse engineering effort. I think TI offered some classes on GPL to licensed developers way back in the golden days of the 99/4A, and I *think* I read somewhere that Rich actually attended such training. But if any effort was made to make an FPGA based processor, IMO it would be better to do the 9900 itself, or some other more open language like Forth or P-code.

[matthew180]

jchase1970, on Thu Feb 2, 2012 7:19 AM, said:

I've thought about this before, so now is a good time to ask.....
If you can have 48k with out banking, does that mean you can do 48k bank switching and if so can you do that as a sidecart like the couple that do exist?

Yes and no. The cartridge port is mapped in at $6000 to $7000, so any side cart trying to repond to RAM / ROM in that range would conflict with any cartridge plugged in to the console. Well, not *any* cartridge technically, but probably 99% of them. GROM only carts would not conflict. You can bank switch the 32K though, and some people have modified their consoles internally to bank switch the whole 64K address range. But only software they write themselves will take advantage of that, so you are limited to new development only, thus it is hard to justify doing such a project other than for yourself, because you want to.

jchase1970, on Thu Feb 2, 2012 7:19 AM, said:

Seems like if sidecarts could have access 48k at once then someone would be able to make anygame that the MSX series runs. They all just need more memory cause they all run in full bitmap mode.

Not really. You have to qualify which MSX you are talking about. MSX1 or MSX2? The MSX1 used the 9918A, thus the graphics are the same as for the 99/4A, CV, etc. and are tile based. The MSX2 had the 9938 which has the true bitmap modes and onboard GPU to do block moves and such, which is the only way to make dealing with a bitmap display possible on a system like that (or on the 99/4A). The CPU simply can't push enough data fast enough to support a real bitmap without the GPU commands in the 9938 and later. The amount of CPU RAM available is irrelavant and would not help. Also, the 9938 had at least 128K available to support those bitmaps, extra graphic information, etc. and the 99/4A does not have that amount of VRAM available. CPU RAM does nothing for the VDP.

However, for the MSX1 games, the main thing holding anyone back is simply motivation. Pick an MSX1 game and start porting, it should be very viable.

[RXB]

matthew180, on Thu Feb 2, 2012 8:28 AM, said:

moulinaie, on Thu Feb 2, 2012 3:17 AM, said:

Willsy, on Wed Feb 1, 2012 1:38 AM, said:

Getting back to GPL, the word is that the GPL byte-code was to be executed by a custom GPL processor - hence the reason that the instruction set is set out very much like a real chip. In order to continue developing the computer before silicon was ready a GPL interpreter/simulator was developed. The silicon never saw the light of day, and we're left with the GPL interpreter that we have today.

Could anyone build this GLP "processor" and install it into the TI-99 ???
As the project of a FPGA to replace the VDP system.

Guillaume.

Yes.

The problem is motivation. There is no market to justify the massive effort, so whoever was working on it would have to be passionate about GPL... Rich... When is your FPGA GPL processor going to be released?

Seriously though, that would be a *HUGE* amout of work for almost no benefit. One of the biggest problems with GPL is that, to this day, it is a closed proprietary language. Just like the GROM, TI never released information about it. The main documentation available is from a reverse engineering effort. I think TI offered some classes on GPL to licensed developers way back in the golden days of the 99/4A, and I *think* I read somewhere that Rich actually attended such training. But if any effort was made to make an FPGA based processor, IMO it would be better to do the 9900 itself, or some other more open language like Forth or P-code.

I am sorry I may have not been clear.
I gave Assembly Classes for people who had interest in Assembly here in Portland and we had some people come in from pretty far away.
The only GPL class I ever had consisted or 2 guys that asked for some help with GRAM devices and to use GPL like Miller Graphics did many tutorials.
I do not think they are even alive today as they were both in their 70s at the time.

Rich