182 replies to this topic

[RXB]

Willsy, on Tue Nov 29, 2011 2:19 AM, said:

Do you have the issue numbers for the Micropendium articles? I'd like to have a read of those articles...

Page 27 Practical EPROM Circuts with diagrams and list of parts. Crap file to big but name is Adobe file mp9008 on the CD ROM under Micropendium in magazines.

Edited by RXB, Tue Nov 29, 2011 3:18 AM.

[RXB]

Sorry wish I could delete a post.

Edited by RXB, Tue Nov 29, 2011 3:19 AM.

[Tursi]

Willsy, on Tue Nov 29, 2011 12:30 AM, said:

Indeed. Sorry, I should have been more clear! I meant in terms of distributing cartridges with GROM data inside them. For example, TurboForth is a 16K ROM application. It would have been nice to have GROM in there too, but it's just not possible yet from a technical standpoint; the cartridge PCB with the GROM/GRAM emulation doesn't exist yet.

Yeah, except for my AVR-based GROM simulator which has existed for almost three years now. As proof of concept, it was recently used by someone here on these forums to reproduce a GROM-only cartridge (first instance to my knowledge except for my demo carts).

http://www.harmlessl...tware/simulator

The reproduction -- I really thought it was posted here, but apparently not! This fellow managed to build a USB-updatable version, his page is here:
http://www.floka.com/grom_gnusb.html

It works. You DO have to do some of your own work to use it in its current form, specifically, you have to compile the code to include your ROM data, program the AVR, and you have to build your own PCB, but that shouldn't scare anyone here anymore.

That said, when I get off my lazy butt (disclaimer: it's a very busy butt!) and finish the changes I want to make, the PCB in that picture will be able to use my code with a whole bunch of other features, and be programmable much more simply in the TI itself. But, given the way things look, even that's a little ways out for me yet.

[RXB]

Emulation of GROM, thanks Tursi that is exactly what could add to any cart someone makes like TurboForth or ROM as this would allow more to be on loaded to the system then from disk.

So my REA with Built in Editor/Assembler/GPL Assembler and a SuperCart is possible thanks to your design.

[apersson850]

I read through this thread. I just have a few comments.
In some places the BL instruction is called Branch and Load, in other places Branch and Link. Branch and Link is the correct name. Not very important, of course.
Regarding BLWP, you can in several places in this thread get the idea that registers 13, 14 and 15 in the calling workspace are used by BLWP. They are not. It's the workspace of the called routine which uses registers 13, 14 and 15 to know which workspace to reload, where it came from and what to load into the status register.
Then we have stacks. The examples above use R10 as a stack pointer and let the stack grow towards higher memory locations. If you want to use the 9900 instruction set as good as possible, and also have the benefit of being able to access the word currently at the top of the stack by a simple *R10, then it's better to let the stack grow towards lower memory location.
Stack declaration, initialization, push and pop are then done like this.

SP	 EQU  10
STACK  BSS  50
STKBOT
START  LI   SP,STKBOT
PUSH   DECT SP
	   MOV  R0,*SP
POP	MOV *SP+,R0
* Subroutines
	   BL  @SUB1
* More code
SUB1   DECT SP
	   MOV  R11,*SP
	   BL   @SUB2
	   B	*SP+
SUB2   DECT SP
	   MOV R11,*SP
	   BL   @SUB3
	   B	*SP+
* and so on, with SUB3 and others defined below

Especially if you want to use the stack for more data than just return addresses, it's very convenient to be able to access the top of stack with *SP, the next word down the stack with @2(SP) etc.

I understand that you who have posted here seems to be mostly interested in speed optimized code for running games. My interest when I used my 99/4A wasn't primarily into that field. I wasn't so careful with memory use either, since one of the best things I did with my 99/4A was when I installed 64 KB of 16-bit wide RAM in the machine. Thus the ordinary memory expansion was replaced with memory where all accesses to words took two cycles, not six. It's like having the scratch pad RAM all over the place.
Due to the ability to shadow console ROM, this also made it possible to modify otherwise fixed interrrupt vectors and such, so the machine was more flexible. My design also allowed paging the ordinary 8-bit memory expansion in and out, to give more storage space.

Edited by apersson850, Sun Jan 22, 2012 8:12 AM.

[Lee Stewart]

apersson850, on Sun Jan 22, 2012 8:07 AM, said:

...
I understand that you who have posted here seems to be mostly interested in speed optimized code for running games. My interest when I used my 99/4A wasn't primarily into that field. I wasn't so careful with memory use either, since one of the best things I did with my 99/4A was when I installed 64 KB of 16-bit wide RAM in the machine. Thus the ordinary memory expansion was replaced with memory where all accesses to words took two cycles, not six. It's like having the scratch pad RAM all over the place.
Due to the ability to shadow console ROM, this also made it possible to modify otherwise fixed interrrupt vectors and such, so the machine was more flexible. My design also allowed paging the ordinary 8-bit memory expansion in and out, to give more storage space.

I, for one, would love to see details of your 64KB-RAM installation and how you used it.

...lee

[apersson850]

Ohh gee, I haven't really used my 99/4A for years. But it's actually all put together and ready to power on, in a room by itself up in the attic (the advantage of a large house...)
Basically, it's two 32 K static RAM circuits piggy-backed on console ROM. Then various LS-TTL circuits to create chip selects and 8 bits of CRU output at 0400H. These bits, when reset, page in the 16-bit RAM where the 32 K memory expansion normally would be. Then I can page in chunks of 8 K RAM at 0000H, 4000H, 6000H and 8000H if I want RAM to overlay the console ROM, DSR, cartridge and console RAM/memory mapped devices. I can also page out the fast memory expansion and page in the normal, 8-bit expansion in the PEB if I want that.
Finally, one CRU bit inserts a wait state on VDP access, since code taking advantage of the fact that you in some cases can omit the recommended "spend time" instruction between certain VDP accesses now will not work any longer, when everything always runs in fast RAM. Code can be run in 8-bit RAM for compatibility, but with this I/O bit set, only the actual VDP accesses need to be slowed down.

Pure assembly programs which run with all code and workspaces in 32 K expansion memory run about 110% faster. Most software does of course use scratch pad RAM for workspace, and accesses VDP and stuff frequently. There the speed gain is smaller. Pascal programs run about 10% faster, BASIC speedup is barely noticeable (probably spends most of the time in the GPL interpreter, which is in 16-bit ROM anyway). Forth increases more than Pascal in speed. Both have their inner interpreters in 16-bit RAM from the beginning, but Forth always runs code from the memory expansion, while Pascal's primary code pool is in VDP RAM.

I used this extra memory together with the memory in my 56 K Maximem module, as well as some more RAM on cards I've designed for the PEB, to create a RAM-disk which worked with the UCSD p-system. Thus files like SYSTEM.EDITOR, SYSTEM.FILER and SYSTEM.COMPILER could reside in RAM. That allowed for faster turnaround when developing software for that system.

I may have some documentation laying around. I'll look for it. Probably best to make a thread by itself for that.

Edited by apersson850, Sun Jan 22, 2012 11:48 AM.

[Lee Stewart]

Thanks, Apersson850---and, welcome aboard!

...lee