Or, reducing frustration
The project has seen a bit of silence recently. I’d apologize but I’m not really all that sorry about it. I’ll offer an explanation:
The process for programming the NVRAM takes 6 minutes for a full update, and the tools I made in BASIC are at best a kludge. If I did anything imperfectly I’d most often have to reload the entire 8k since I don’t have a debugger yet.
PROMAL is a high level compiled application language originally written for the C-64, Apple2, and IBM PC running DOS. To date, Ive only managed to find the C-64 version ShadowM has on his site.
PROMAL is a native development environment including a functional editor and commandline environment that supports passing arguments to programs being called. This is a great advantage, as a user can just specify an action as well as a target, rather than having the action app request what the target is intended to be.
As PROMAL is a compiled language, it does tend to run a bit more efficiently. There are also other things that can be done in the language that enables one to increase efficiency. For example, the most common data type is a 16bit word rather than a 40bit float. All those loops in the BASIC program? The address counters, the data byte… all of those are stored and processed as floats. Not so in the programs below, as I only use ‘byte’ and ‘word’ variables, which are optimally sized as 8 bit and 16 bit unsigned numbers, respecitvely.
How much more efficient than BASIC is this implementation? In this specific application we’re looking at a speed increase of 383%. Nearly four times the operational speed. There’s light at the end of the reprogramming tunnel the moment enter is pressed!
Another advantage of PROMAL is the ability to define where a variable rests in memory. Take the nvdefs.s file below as an example:
ext byte via1 at $de20
There are some key words here: ‘ext’ refers to an external reference. ‘byte’ defines the variable’s values to be stored as bytes. The name ‘via1’ is assigned and the brackets indicate the variable is an array. Finally, the specified address is $de20. Readers might remember the address of the first VIA on the IO card I’m using for this project being at that address.
What does this do for me? It’s simple. I use the constant also defined in nvdefs.s called ‘porta’ to set up the output pins as desired, without a poke or a lot of math: via1[porta]=$ff. This causes the value of porta to be offset into the via1 array, and a $ff is stored there, turning all bits on. No run around looking up a variable, getting its value, then converting the float to an unsigned integer, setting up a vector, loading porta into an index, and hten finally storing. It just skips the second through fifth steps. You might also notice ‘addr’ in nvdefs, which is a WORD type set at DE20. This means any 16bit address stored in the ‘addr’ variable is automatically stored to both port a and port b on the first via at that address. No address splitting or additional processing. This all adds to speed, which really matters when you only have approximately 300,000 operations/second available.
Below is the nvdefs.s file I created for the project. PROMAL includes among other things the ability to include secondary files in the same way the modern C compiler has headers. These files are considered part of the compiler’s input stream at the position they’re included, and can provide hardware and operating system abstraction. If the apple2 version of PROMAL weren’t made of unobtanium and a “john bell” 32bit IO card were in use, nvdefs.h could be changed to reflect the IO port addresses for the apple2 card and the application below could be used without modifications after a simple recompile.
File: nvdefs.s ;DEFs for nvram read/write via Schnedler ultimate interface ;IF VIAS CHANGE also change named items below. ; assume VIA1 is at DE20, VIA2 at DE30 ext byte via1 at $de20 ext byte via2 at $de30 con ddra=3 con ddrb=2 con pa=1 con pb=0 ; Named items for nvram config: ; Bits on control port: WE CS OE nc nc nc nc nc con off=$e0 ; chip offline con wr =$20 ; chip write con rd =$80 ; chip read ; Named items for via control con in=0 ; for DDR con out=255; for DDR ; Named items for nvram address/data bus ext word addr at $de20 ; access via1 ports a and b as 16bit unsigned! ext byte dat at $de31 ; via2 port a for data bus ext byte dc at $de33 ; via2 port a ddr for data in/out ext byte ctl at $de30 ; via2 port b for chip control
And now the tool written to reprogram the NVRAM, rewritten in PROMAL. It accepts its parameters from the commandline, making it easy to specify what needs to be done.
File: nvwr.s program nvwr include library include nvdefs word a ; address presented to nvram word length ; number of bytes to prog word file ; file handle word total ; total bytes written byte d ; data byte to program byte t ; scratch space begin total=0 a=0 length=$ffff if ncarg < 1 put "Usage: nvprog <file> [addr] [len]",nl put " All values are specified",nl put " in hexadecimal.",nl,nl abort file=open(carg) if file=0 put "Unable to open ",carg,nl abort if ncarg>1 t=strval(carg,#a,16,4) ; address if ncarg>2 t=strval(carg,#length,16,4) ; bytes to program output "Loading $#4H bytes from ",length put carg," into NVRAM.",nl ctl=off via1[ddra]=out via1[ddrb]=out dc=in via2[ddrb]=out while getcf(file,#d) and length>0 ctl =off ; ensure chip is offline addr=a ; set up address bus dat =d ; set up data bus dc =out ; drive data bus ctl =wr ; write byte (cs,we) ctl =off ; back offline dc =in ; prep for verify ctl =rd ; re-read byte if dat <> d ; live compare data bits on ram with d put "ERROR: failed to verify byte",nl output "#4H >#2H <#2H#C",a,d,dat abort length=length-1 ; count bytes left to program total=total+1 a=a+1 close(file) output "Wrote #4H bytes.#C",total end
Sadly, I don’t offer anything in the way of pictures in this post, but I hope the information was interesting regardless. Real Soon Now(TM) I’ll be able to get a more featured toolset for getting my minimal debugger going on the IIEasy Print card. Once the machine language monitor is fully functional, everything will suddenly become very simple.
To learn more about PROMAL, you can download the documentation easily from ShadowM’s webpage.