Give your 4A a new Brain!

[Tursi]

I've been working for almost a week now on a new project (because, as everyone knows, I have plenty of free time and nothing that I am supposed to be working on... but I digress...)

 

I was toying around with ideas for what exactly to do with the GROM sim project I did, since there's not a huge amount of need for GROMs from people. Except for reproducing important cartridges like the Editor/Assembler or Extended BASIC (assuming they ever become hard to come by), it didn't seem to have much value.

 

As some of that, I created my Editor/Assembler 'Complete', which I showed at the Chicago Faire last year. This has the EDIT1, ASSM1 and ASSM2 files built into the GROM, so it doesn't need to find them on disk. It was something I always wished for, and I toyed with the idea of making carts for people and sending them out.

 

Then I fell back on a promise I made for Matthew at the faire, I popped my console open to measure the performance difference using my simulated (and in theory faster) GROMs than the console GROMs. Somewhat to my surprise, I found that although my simulator was 2-4 times faster than a real GROM, it made very little difference in the performance of the console, or BASIC. After some investigation, I identified that the GPL interpreter spends less than 5% of its time reading GROM, so speeding up that 5% has a very small impact overall.

 

But it made me think, it would be neat to ship a replacement GROM, then I could put E/A Complete right in the console. And using a Microcontroller as the GROM means I have the flexibility to do some rather sneaky tricks. And the sneakiest trick I could think of at the time, was to run the 99/4 GROM on the 99/4A.

 

An early test got it running successfully, although I had to overcome the keyboard issue. I have plenty of technical notes on that now, but ultimately this led to the development of a project that I call (and please forgive the bad pun), the Multiple Personality Distorter, or MPD for short.

 

I don't have it at the point yet where I can load it on the real console and try it, but the emulation is working very well, and at this point, all of the existing software I meant to load is working. This project lets you select, via a configuration menu, replacements for the console GROMs.

 

For GROM0, you can select 99/4, 99/4A, v2.2, 99/8, and my own custom shell (still to be developed).

For GROM1 and 2, you can select TI BASIC, Editor/Assembler Complete, or a combination GROM with Disk Manager 1000 and Archiver 3.03.

 

All of these have been ported and relocated, and are running fine in their new homes. Naturally E/A, DM1000 and Arc303 will require 32k RAM available to function. Editor/Assembler was a pain to relocate (from >6000 to >2000), and I ended up writing a tool to parse GPL and handle the relocation as automatically as possible. I don't know if it will work on any other GROMs and I decided not to bother trying. The others I simply made GROM carts from inside Classic99 and tweaked up the headers to combine them and handle the page-flipping needed.

 

Now, before you get too excited about some of the first list (I hope someone is excited, anyway, otherwise it's just me), let me note what had to change.

 

The 99/4 required the most work, since it was not designed to work with the 99/4A ROM. In particular, the keyboard scanning was a big deal. Keyboard scanning happens in the ROM, which is nice because we still have a 4A keyboard, but the keyboard TABLES are in GROM0. Originally I actually worked out an automatic paging system, but ultimately I ended up just moving the tables into the 99/4 GROM and relocating what they overwrote. Because I have 8k GROMs (like RXB says!), I was able to spill some things over into the extra 2k space.

 

The 99/4A of course, is the base system so did not require any modifications. Likewise, the v2.2 console uses the same ROM as the original 99/4A, so it also worked out of the box.

 

The 99/8 is a fake, I'm sorry to admit. I looked at the 99/8 GROM, but although I can see similarities, there's a lot of different hardware initialization going on in there, and since none of the additional features will be useful, all I did was port the relavant parts back to the 99/4A GROM0. It /looks/ just like a 99/8 when it starts, as I fixed up all the screens and even ported the 99/8 font (thanks to Sometimes99er for noting in his thread that it was different!). I even wrote the 'SET SPEED' option, although it doesn't do anything. So you get the nice 99/8 font with true lowercase and you get the 99/8 selection screen, but otherwise it's a 99/4A.

 

My own GROM will be a psuedo GUI, with a small shell if I can manage it. Too early to say much on this.

 

Right now I'm working on the config screen, which is all that it's worth showing a screenshot of (the other screens all look like ordinary console screens, not much to see there! But a video will come once config is working). I mocked it up in Extended BASIC, and although I hand-ported to GPL, instead of using that I'm writing a tool to compiled simple Extended BASIC as GPL. It only supports what I'm using, but maybe it's a start.. we'll see when I get it done. That's about 50% and so far the generated GPL looks good.

 

The project is sitting at about 120k of GROM, internally managed (ie: does not use multiple GROM bases - this would cause problems with cartridges that did, and it's not available from a GROM socket anyway, you need a few more address lines. ) Ultimately, the goal is a small PCB, pop the console open, remove the three GROMs there, and plug the board into the GROM sockets. This project works by paging the GROM internally, including logic for saving state and automatic reset, so it won't actually work on GRAM Krackers.

 

So, screenshot:

 

----------------

 

For those curious, here were my memory benchmark results.

 

I wrote a simple benchmark program and measured the time with my logic analyzer. The loop runs in scratchpad with scratchpad registers, and just copies 6k like this:

 

LP
   MOVB *R10,R0        * into a register for speed
   MOVB *R10,R0        * twice to minimize the cost of the loop
   DECT R1
   JNE LP

 

Note the slight unroll - since GROMs actually hold the CPU, you don't really need to delay. Also note I don't spend any time on increments. Anyway, just for kicks, these are the results, on real hardware with stock clock (and console GROMs were removed for my GROM tests - if console GROMs are installed then all GROMs run at the speed of the slowest GROM).

 

Time to copy 6k to scratchpad (register destination and indirect register source):

 

SourceAddress: Time:

16-bit RAM: 58ms

8-bit RAM: 65ms (+12%)

20MHz GROM: 75ms (+29%)

8MHz GROM: 88ms (+51%)

TI GROM: 113ms (+94%)

 

I thought that was rather telling. Although GROM is a LOT slower than RAM, especially scratchpad RAM, in normal usage patterns, the difference is not as great as we'd been led to believe. (Note that the difference between 16-bit RAM and 8-bit RAM is /data/ access only -- putting your code in scratchpad versus code in 8-bit RAM means that small hit happens nearly every single cycle, and it does cost a lot.)

[sometimes99er]

Very interesting - and very cool.

 

I'm an emulation only and cross assembler guy, but this is what dreams are made of. Imagining if someone told me something like this in 1982.

 

[rocky007]

really interesting, but i've a stupid question :

 

Is it a advantage in choosing 99/4 for a 99/4A ?

[+retroclouds]

Hey how about putting the UCSD P-code card on there? That way you could use the P-code with the nanopeb/CF7+

That would make a nice environment for those who do not have a P-BOX.

 

If I'm not mistaking the later TI-99/8 prototypes had P-Code installed.

Edited April 7, 2011 by retroclouds

[Tursi]

really interesting, but i've a stupid question :

 

Is it a advantage in choosing 99/4 for a 99/4A ?

 

Not that I can see!

 

But it's a curiousity. Not everyone has seen a physical 99/4. I thought it was bloody awesome the first time I saw one boot outside of emulation.

[Tursi]

Hey how about putting the UCSD P-code card on there? That way you could use the P-code with the nanopeb/CF7+

That would make a nice environment for those who do not have a P-BOX.

If I'm not mistaking the later TI-99/8 prototypes had P-Code installed.

 

Hm. That's an interesting idea. I have a number of problems it creates though...

 

I don't have a P-Code card and the Classic99 emulation of the P-Code doesn't work (although I suppose I have the tools to fix it now ), so that will make testing it pretty difficult. A bigger problem is that the P-Code GROMs run at a different address base than the console GROMs, so to make them work from the console GROM port will require them to be relocated, and they will have to overwrite GROM space (but I suppose you'd not need a cartridge with the P-Code loaded).

 

The killer, though, is that the P-Code card requires ROM. There's no way to access ROM through the console GROM sockets, and the console ROMs are not socketted, meaning such a mod would require soldering.

 

This would not prevent making a P-Code /cartridge/, however. But you would need to do the following to make a cart:

-Relocate the DSR ROM to >6000 from >4000

-Modify the DSR ROM paging scheme to use the 379 style paging instead of CRU bits (easier than implementing CRU on the cart)

-Relocate the P-Code GPL code, if necessary (likely so)

-Adapt any code in the ROM or GROM that works with the GROM base being in DSR space

 

The one issue I see with the above, besides being quite time consuming and test intensive, is that the P-Code GROMs I have use the entire 64k address space, but a cartridge has only 40k of space to work with. It's possible, since you have to relocate anyway, that you might be able to pack it using 8k GROMs. 64k of GROM space with 6k GROMs is only 48k of data, and perhaps some is unused. Without a disassembly this starts getting very difficult.

 

I didn't know anyone actually used the P-Code card anymore. I also thought I heard a rumour that a cartridge was done once.. anyone else remember that?

[+retroclouds]

Yeah, guess there are some challenges ahead if you'd go down that road

A pcode cartridge combined with the CF7/nanopeb would make a *very* nice bare metal development system.

 

The P-Code system is quite powerful. In my opinion the biggest mistake that TI made was to put it in a card instead of a cartridge. I also think it could have been much more popular if it had been widely available.

I tried for years getting one in Europe and failed. With the help of Owen I'm now the proud owner of one

 

Michael Zapf told me that UCSD Pascal is now fully emulated in MESS, haven't checked that out yet.

 

A cartridge version apparently was done in Germany at one time. As far as I know, it wasn't a physical version.

It was a prototype image running on a GRAM Kracker or compatible device.

I asked around at the regional TI treff if someone knew about this, but couldn't get more details.

Most likely the images are lost by now

 

 

EDIT: Just found this cross-compiler, sure seems interesting: http://ucsd-psystem-xc.sourceforge.net/

Edited April 8, 2011 by retroclouds

[Tursi]

UCSD Pascal was big on a number of systems, and was one of the first moderately successful byte-code systems. As for TI's mistake... it wouldn't have worked directly on a cartridge, but for all the hardware needed on a PEB card, they could just as well have used multiple GROM bases to get the necessary amount of GROM space. Agreed that a cartridge would have been better. I wonder if something in their licensing required it to take over the system at boot? Maybe to avoid piracy?

 

That said, I don't think there's enough support for it now. Turbo-Forth is going to kick the pants off the Pascal card for performance, and is a better overall product, IMO, thanks to modern tools and hardware. You can use it in conjunction with yout CF7 as well. For me, supporting the CF7 is not a priority. The P-Code card is supported in MESS and PC99, yes. (And Classic99 includes it, but I haven't had a chance to look at it again since adding disk image support, should be able to make it work now.)

 

I think I will leave cartridging it to someone else. I'll be happy to share my tools if someone wants to use them as a starting point, but it's still going to take a lot of manual labor unless you can find a disassembly of the GROMs.

[Tursi]

Back to the topic at hand, I got my converter working, and so now my first full GPL program is working, that being the configuration tool. I've posted a video of the MPD running under Classic99, with a voice-over explanation, here:

 

I also posted the two GPL utilities I wrote for this project. They are hacky and somewhat incomplete, but they were useful to me and someone else may find them useful too.

 

XB2GPL compiles a limited subset of Extended BASIC to GPL binary - http://harmlesslion.com/software/xb_2_gpl

GROM Relocate traces GPL execution and outputs a relocated binary - http://harmlesslion.com/software/relocate

 

Neither has a nice user interface and both have their share of uglies, but source is included and they did their job for me.

Edited April 8, 2011 by Tursi

[Willsy]

Wow! I think I just had my brains blown out! This awesome! I want one for my real TI! The "Fat EA" is worth it alone, and a disk manager... Yowzers...!

 

Want one.

 

Want it now!

[+Vorticon]

Tursi, are you going to make some kind of kit for the rest of us? Maybe a group buy?

[RXB]

Very cool. If you ever owed a TI calculater (They made tons of the like HP) then you would see why it has TI CALC. They are almost a dupicate of function and form.

You could plot a graph and draw similar to TI LOGO on it but using math instead of LOGO.

 

If anyone needs it I have a EA GROM souce of a better INIT used for Load and Run then the horrid TI one that was written before they knew about the GPL MOVE command in the ROM.

 

Here is the Source attatched. I saved so much space in GPL I could write a new AMS support section.

 

If you have ever seen the EA cart source of the EA version of INIT you would almost cry it is so complicated and wastes so much space, and is slower.

RXBGPL(EAcart)Source.zip

[Tursi]

Tursi, are you going to make some kind of kit for the rest of us? Maybe a group buy?

 

That is my goal, yes! The next step is to get it running on hardware, should have that this weekend (since most of the pieces already exist - I just need to write the EEPROM interface code). After that, it's writing my little GUI. That will take longer, as I have to decide what language to build it in. I may use XB now that my GPL compiler is working, since even with the extra commands I will need, it will be faster to develop, test, and build than raw GPL. We'll see.

 

Then the last step is designing the PCB and getting some on order. I'm happy to see some interest in it! I've put a lot of late nights into this. I've also fully documented all the tweaks I had to make, so anyone interested in the under-the-hood parts will have plenty to read.

[Tursi]

Very cool. If you ever owed a TI calculater (They made tons of the like HP) then you would see why it has TI CALC. They are almost a dupicate of function and form. You could plot a graph and draw similar to TI LOGO on it but using math instead of LOGO.

 

Are you saying the 99/4 Equation Calculator has graphing?

 

If anyone needs it I have a EA GROM souce of a better INIT used for Load and Run then the horrid TI one that was written before they knew about the GPL MOVE command in the ROM.

 

... how could they have been writing GPL at TI before knowing there was a MOVE command?

 

hehe... anyway, nice!

[RXB]

Very cool. If you ever owed a TI calculater (They made tons of the like HP) then you would see why it has TI CALC. They are almost a dupicate of function and form. You could plot a graph and draw similar to TI LOGO on it but using math instead of LOGO.

 

Are you saying the 99/4 Equation Calculator has graphing?

 

If anyone needs it I have a EA GROM souce of a better INIT used for Load and Run then the horrid TI one that was written before they knew about the GPL MOVE command in the ROM.

 

... how could they have been writing GPL at TI before knowing there was a MOVE command?

 

hehe... anyway, nice!

 

 

Well some models of the TI calculators did have some Graphing they could do on that tiny LCD screen. I suppose you would have to use character definitions and plot like many people have which is pretty slow.

The Calculators had hardware to do this, the TI99 only had Basic. But that was what lead to Logo(Mini Forth) being develouped.

 

If you look at my Source code of XB and of the XB ROM source code you will see that they often state in the notes that some routines like MVUP and MVDN were written before they knew about the MOVE command in GPL. Wish I still had the XB ROM source code it said this through out the source code.

Just stating facts. When you have guys working on a project and do not know what others are doing they use the tools they know about. Many notes say this.

Here are the facts:

<0273> ***********************************************************

<0274> * ASSEMBLY LANGUAGE SUPPORT FOR 99/4

<0275> *

<0276> * LOAD, INIT, PEEK, LINK, CHARPAT JDH 08/21/80

<0277> ***********************************************************

<0278> * FORMAT FOR LOAD:

<0279> * CALL LOAD open load-directive (comma load-directive)

<0280> * close

<0281> * load-directive = file-name / address (comma data)

<0282> * (null / file-name)

<0283> * file-name = string-expression

<0284> * address = numeric-expression

<0285> * data = numeric-expression

<0286> *

<0287> * FILE TYPE = FIXED 80, DISPLAY , SEQUENTIAL FILE

<0288> *

<0289> * FUNCTION:

<0290> * LOADS ASSEMBLY LANGUAGE CODE INTO EXPANSION RAM

<0291> * ADDRESSES: >2000 - >>3FFF RELOCATING

<0292> * RELOCATABLE CODE INTO AVAILABLE MEMORY, ABSOLUTE CODE

<0293> * IS LOADED

<0294> * INTO ITS ABSOLUTE ADDRESS, ENTRY POINTS ARE DEFINED BY

<0295> * 'DEF' STATEMENTS, AND ARE LOADED INTO HIGH END OF ERAM

<0296> *

<0297> * RELOACATABLE OR ABSOLUTE CODE MAY BE STORED ON A FILE

<0298> * 9900 OBJECT CODE FORMAT.

<0299> * VALID TAGS = 0, 5, 6, 7, 9, A, B, C, F,:

<0300> * TAGS 1, 2, I, M, ARE IGNORED

<0301> * THE SYMT OPTION IS NOT SUPPORTED.

<0302> * ABSOLUTE CODE MAY BE LOADED DIRECTLY FROM PROGRAM

<0303> * BY SPECIFYING AN ADDRESS INSTEAD OF A FILE NAME,

<0304> * FOLLOWED BY THE DATA TO BE LOADED (WHICH IS PUT IN THE

 

99/4 GPL-ASSEMBLER (Pass 3) correct PAGE 0012

EQUATES ALCS-359

<0305> * RANGE 0 to 255

<0306> * THE RANGE OF THE ADDRESS OR DATA IS LIMITED TO

<0307> * 32767 to -32768

<0308> * MULTIPLE DIRECT LOADS CAN BE IN THE SAME LOAD COMMAND

<0309> * PROVIDED THEY ARE SEPARATED BY EITHER A FILENAME OR A

<0310> * NULL STRING.

<0311> *

<0312> * MVUP WAS USED TO TRANSFER DATA FROM CPU RAM TO ERAM <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

<0313> * SINCE IT WAS NOT KNOWN AT FIRST THAT THE MOVE <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

<0314> * INSTRUCTION COULD TRANSFER FROM CPU RAM TO ERAM <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

<0315> * (PROVIDED THAT >8300 IS SUBTRACTED FROM THE ADDRESSES) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

<0316> ***********************************************************

<0317> ******************* LINKAGE AND HEADER ********************

<0318> C000 AA BYTE >AA

<0319> C001 00,00,00 BYTE 0,0,0

<0320> C004 00,00,00 BYTE 0,0,0,0,0,0

C007 00,00,00

<0321> C00A 00,00 DATA 0

<0322> C00C 00,00,00 BYTE 0,0,0,0

C00F 00

<0323> C010 C0,19 LINK1 DATA LINK2

<0324> C012 04,4C,49 STRI 'LINK'

C015 4E,4B

<0325> C017 C3,25 DATA LINKIT

<0326> C019 C0,22 LINK2 DATA LINK3

<0327> C01B 04,4C,4F STRI 'LOAD'

C01E 41,44

<0328> C020 C0,40 DATA LOAD

<0329> C022 C0,2B LINK3 DATA LINK4

<0330> C024 04,49,4E STRI 'INIT'

 

My code is from my copy of the XB source code.

Edited April 9, 2011 by RXB

[Tursi]

RXB, this thread isn't about the TI Calculators.

 

As for the comment about MOVE, a simple "yes" would have sufficed. hehe

[RXB]

RXB, this thread isn't about the TI Calculators.

 

As for the comment about MOVE, a simple "yes" would have sufficed. hehe

 

 

I wish I had the XB Source code for the XB ROMs as then I could dump the junk that was in there like MVUP and MVDN also I could fix the other problems that I found. To bad my SCSI drive died.

[+Vorticon]

UCSD Pascal was big on a number of systems, and was one of the first moderately successful byte-code systems. As for TI's mistake... it wouldn't have worked directly on a cartridge, but for all the hardware needed on a PEB card, they could just as well have used multiple GROM bases to get the necessary amount of GROM space. Agreed that a cartridge would have been better. I wonder if something in their licensing required it to take over the system at boot? Maybe to avoid piracy?

 

That said, I don't think there's enough support for it now. Turbo-Forth is going to kick the pants off the Pascal card for performance, and is a better overall product, IMO, thanks to modern tools and hardware. You can use it in conjunction with yout CF7 as well. For me, supporting the CF7 is not a priority. The P-Code card is supported in MESS and PC99, yes. (And Classic99 includes it, but I haven't had a chance to look at it again since adding disk image support, should be able to make it work now.)

 

I think I will leave cartridging it to someone else. I'll be happy to share my tools if someone wants to use them as a starting point, but it's still going to take a lot of manual labor unless you can find a disassembly of the GROMs.

Since I am planning on doing my next project in Pascal, I would love it if the P-Code in Classic 99 is fixed. Using the P-Code environment on the real machine is a pain in the butt at best, and slow, although pretty stable from my testing. Pleeeeaaaase ???

[+OLD CS1]

Back to the topic at hand, I got my converter working, and so now my first full GPL program is working, that being the configuration tool. I've posted a video of the MPD running under Classic99, with a voice-over explanation, here:

 

Neat-o shit! However, I will continue to pronounce the "G-ROM" as "grom".

[Tursi]

Since I am planning on doing my next project in Pascal, I would love it if the P-Code in Classic 99 is fixed. Using the P-Code environment on the real machine is a pain in the butt at best, and slow, although pretty stable from my testing. Pleeeeaaaase ???

 

hehe, I will look at it. No promises as I don't actually know why it doesn't work today! (But in fairness, I know a lot more today than I did last time I looked at it.) Still, I do kind of question the value since it's not widely distributed in real life. (Of course, if the value is "because I want to do it", I never question that value ).

 

I would note that since the P-Code card is mostly GROM, that the Classic99 debugger won't help a lot, at least not stepping through code. I guess the memory investigation is still nice. I have learned a few tricks for GPL debugging though, and I have considered adding a GPL debug mode, at least a limited one. But in the meantime, these are the two things that I have used a lot:

 

1) Breakpoint on a particular GPL instruction - set a breakpoint for a GROM read from the address of the instruction. IE: to breakpoint at a GPL instruction at G@>6100, use "<G6000" as the breakpoint. Note that the GROM address is incremented so when you look at it in the debugger, it's at least one and sometimes two bytes ahead (the 2 may be a bug, I didn't look at it, but be aware).

 

2) Single-step GPL - set a break point at >007A ("007A" with no prefixes in the debugger). At this point, the GPL opcode is loaded into the MSB of R9, so you can see what is about to be executed, and this is after the console interrupt has run (if it was going to), so it's a great place to stop. With the breakpoint set, pressing F1 (run) will execute just the one GPL instruction before stopping again.

 

Sometimes the screen doesn't redraw in time before a breakpoint (this can happen in assembly as well as GPL). If that happens, just hit F9 (draw character set) and then hit it again to redraw the screen.

 

Working on the hardware port right now, hoping to have something tonight, but I'm being lazy about it and browsing forums.

[RXB]

Since I am planning on doing my next project in Pascal, I would love it if the P-Code in Classic 99 is fixed. Using the P-Code environment on the real machine is a pain in the butt at best, and slow, although pretty stable from my testing. Pleeeeaaaase ???

 

hehe, I will look at it. No promises as I don't actually know why it doesn't work today! (But in fairness, I know a lot more today than I did last time I looked at it.) Still, I do kind of question the value since it's not widely distributed in real life. (Of course, if the value is "because I want to do it", I never question that value ).

 

I would note that since the P-Code card is mostly GROM, that the Classic99 debugger won't help a lot, at least not stepping through code. I guess the memory investigation is still nice. I have learned a few tricks for GPL debugging though, and I have considered adding a GPL debug mode, at least a limited one. But in the meantime, these are the two things that I have used a lot:

 

1) Breakpoint on a particular GPL instruction - set a breakpoint for a GROM read from the address of the instruction. IE: to breakpoint at a GPL instruction at G@>6100, use "<G6000" as the breakpoint. Note that the GROM address is incremented so when you look at it in the debugger, it's at least one and sometimes two bytes ahead (the 2 may be a bug, I didn't look at it, but be aware).

 

2) Single-step GPL - set a break point at >007A ("007A" with no prefixes in the debugger). At this point, the GPL opcode is loaded into the MSB of R9, so you can see what is about to be executed, and this is after the console interrupt has run (if it was going to), so it's a great place to stop. With the breakpoint set, pressing F1 (run) will execute just the one GPL instruction before stopping again.

 

Sometimes the screen doesn't redraw in time before a breakpoint (this can happen in assembly as well as GPL). If that happens, just hit F9 (draw character set) and then hit it again to redraw the screen.

 

Working on the hardware port right now, hoping to have something tonight, but I'm being lazy about it and browsing forums.

 

If you have a copy of the GPL code send it to me, maybe I can find the problem and fix it from a GPL viewpoint.

[Tursi]

If you have a copy of the GPL code send it to me, maybe I can find the problem and fix it from a GPL viewpoint.

 

Thanks for the offer, but I don't know what problem you are offering to help with!

 

If you mean the P-Code card, it's an emulation problem, not a GPL problem.

Edited April 10, 2011 by Tursi

[Tursi]

I got the MPD working with the hardware today. It went fairly smoothly, the main issue I had was not remembering that the AVR only has a 64k address space, and I had to do something special to access data beyond that.

 

[ti99iuc]

Tursi, I was speechless !!! WOW !

[+Vorticon]

Very cool! From a practical standpoint though, how do you plan on incorporating this inside the console? Or do you just plan on keeping the microcontroller board external?