Line-by-line assembler

[+jedimatt42]

was something like the mini-memory line-by-line assembler ever adapted to ROM or disk-image to use with 32k space instead of off cassette in the mini-memory cartridge?

 

-M@

[+jedimatt42]

I realize If I had a disk system I could use fbForth's assembler for what I want to do, but I want to not have a disk system. Just a cartridge, and avoid cassette loading times...

 

-M@

[Sinphaltimus]

I realize If I had a disk system I could use fbForth's assembler for what I want to do, but I want to not have a disk system. Just a cartridge, and avoid cassette loading times...

 

-M@

And be able to take advantage of using the disk buffer ram which I think the MMM does. Or am I mixing things up a bit?

[+jedimatt42]

And be able to take advantage of using the disk buffer ram which I think the MMM does. Or am I mixing things up a bit?

 

My understanding is that the disk-buffer is allocated in VDP, so if you have no disk, you can just use it!

 

I want to fiddle is assembler, on a machine that has just my 32k, and a flashrom or other cartridge attached, and some other hardware that needs fiddling with... I can kind of due what I want in EasyBug, or EA-V's debugger. I want CRU access so I don't know how to do that in fbForth without loading the assembler or cru words from fblocks... I'm trying to debug CRU selection... and I have physical space/desk constraints that prevent hooking up a disk drive.

 

What a privileged problem to have

 

-M@

[+acadiel]

I think I had converted it to disk a long time back. Let me check my files.

[Stuart]

acadiel, on 02 Jan 2017 - 7:15 PM, said:

I think I had converted it to disk a long time back. Let me check my files.

 

I've got it disassembled somewhere, so if you haven't got it on disk, it shouldn't take too much effort to make a cartridge out of it to use the 32K RAM,

[+Lee Stewart]

... I want CRU access so I don't know how to do that in fbForth without loading the assembler or cru words from fblocks... I'm trying to debug CRU selection... and I have physical space/desk constraints that prevent hooking up a disk drive.

 

What a privileged problem to have

 

-M@

 

You can certainly type the CRU words into fbForth by hand as they appear in FBLOCKS. You would be typing in machine code, so you would not need the assembler. Even though they are not long, typing them in would still likely be more tedious than you might like, however.

 

...lee

[+jedimatt42]

 

You can certainly type the CRU words into fbForth by hand as they appear in FBLOCKS. You would be typing in machine code, so you would not need the assembler. Even though they are not long, typing them in would still likely be more tedious than you might like, however.

 

...lee

 

Still probably faster than pulling up the line-by-line assembler. It is not a bad idea at all.

 

-M@

[+acadiel]

ftp://ftp.whtech.com/Cassettes/Mini_Memory/ - There's the WAV for the Line by Line Assembler/Lines.

 

I *think* the LINES (EA/3) program is on this disk (Attached). We can probably use Rag Linker and make it a PROGRAM image file and then copy it to expansion RAM as part of an UberGROM cart or something.

 

EAMISC.DSK.zip

[+Lee Stewart]

 

Still probably faster than pulling up the line-by-line assembler. It is not a bad idea at all.

 

-M@

 

H-m-m-m—there is actually room to put the CRU words into the resident dictionary. I could, at least, generate a build of fbForth 2.0 for you—even if I don't make it an official release. Or—maybe it should be an official release. What do you think?

 

...lee

[+jedimatt42]

 

H-m-m-m—there is actually room to put the CRU words into the resident dictionary. I could, at least, generate a build of fbForth 2.0 for you—even if I don't make it an official release. Or—maybe it should be an official release. What do you think?

 

...lee

 

That's generous, but typing in a couple sentences is pretty painless.

CODE SBO C339 , A30C , 1D00 , NEXT,
CODE SBZ C339 , A30C , 1E00 , NEXT,

And I learned something along the way Maybe this is right, maybe it is wrong. I think there is something misleading on page 29 of 'How to build your own working 16-bit microcomputer' by Ken Tracton. It seems to contradict the need to shift the CRU address left 1. You only get 12 bits to address cru-bits. A0-A2 are zero, then A3-A14 are your 12-bit address, and well A15 doesn't matter. So, when I'm thinking about code to address a DSR enable bit for instance, for something at CRU >1F00, it seems to me I should load R12 with 1F00... But that would be counting the cru-bits by 2s.. So it seems there is a convention of talking about hardware addresses in this counting by 2s model... All the CRU Base addresses for cards are described as >1xxx, you can't shift that left or you lose the 1. But lots of software libraries talk about remembering to shift your bit... so that must mean using a counting by 1s mental model.

 

So, if I use the machine code above, where >A30C comes from R12 R12 Add (Yoda assembly ), and I want to address cru-bit 0 with cru-base >1F00, then I suppose I load R12 with >1F00 / 2 ...

 

That seems pretty weird to me. Because I'm playing with hardware, and really care about the individual address lines and their state, trying to decode the cru-addressing.

 

Is that where this shifty (pun) convention came from... Software side wanting to think of it as specifying 1 of 4096 cru-bits, counting by 1s?

 

I believe I can skip the doubling of R12 if I set R12 to the state I want the address lines to be in.

 

-M@

[+Lee Stewart]

 

That's generous, but typing in a couple sentences is pretty painless.

CODE SBO C339 , A30C , 1D00 , NEXT,
CODE SBZ C339 , A30C , 1E00 , NEXT,

And I learned something along the way Maybe this is right, maybe it is wrong. I think there is something misleading on page 29 of 'How to build your own working 16-bit microcomputer' by Ken Tracton. It seems to contradict the need to shift the CRU address left 1. You only get 12 bits to address cru-bits. A0-A2 are zero, then A3-A14 are your 12-bit address, and well A15 doesn't matter. So, when I'm thinking about code to address a DSR enable bit for instance, for something at CRU >1F00, it seems to me I should load R12 with 1F00... But that would be counting the cru-bits by 2s.. So it seems there is a convention of talking about hardware addresses in this counting by 2s model... All the CRU Base addresses for cards are described as >1xxx, you can't shift that left or you lose the 1. But lots of software libraries talk about remembering to shift your bit... so that must mean using a counting by 1s mental model.

 

So, if I use the machine code above, where >A30C comes from R12 R12 Add (Yoda assembly ), and I want to address cru-bit 0 with cru-base >1F00, then I suppose I load R12 with >1F00 / 2 ...

 

That seems pretty weird to me. Because I'm playing with hardware, and really care about the individual address lines and their state, trying to decode the cru-addressing.

 

Is that where this shifty (pun) convention came from... Software side wanting to think of it as specifying 1 of 4096 cru-bits, counting by 1s?

 

I believe I can skip the doubling of R12 if I set R12 to the state I want the address lines to be in.

 

-M@

 

Yeah, even the E/A Manual is confusing when talking about CRU bits vs. their actual addresses. Here is what I put in the fbForth 2.0 Manual:

 

 

...lee

[+jedimatt42]

Of course! I read your assembly addendum for the words, and forgot to go read your narrative.

 

It is starting to make sense now.

 

-M@

[Stuart]

jedimatt42, on 03 Jan 2017 - 12:31 AM, said:jedimatt42, on 03 Jan 2017 - 12:31 AM, said:jedimatt42, on 03 Jan 2017 - 12:31 AM, said:

 

That's generous, but typing in a couple sentences is pretty painless.

CODE SBO C339 , A30C , 1D00 , NEXT,
CODE SBZ C339 , A30C , 1E00 , NEXT,

And I learned something along the way Maybe this is right, maybe it is wrong. I think there is something misleading on page 29 of 'How to build your own working 16-bit microcomputer' by Ken Tracton. It seems to contradict the need to shift the CRU address left 1. You only get 12 bits to address cru-bits. A0-A2 are zero, then A3-A14 are your 12-bit address, and well A15 doesn't matter. So, when I'm thinking about code to address a DSR enable bit for instance, for something at CRU >1F00, it seems to me I should load R12 with 1F00... But that would be counting the cru-bits by 2s.. So it seems there is a convention of talking about hardware addresses in this counting by 2s model... All the CRU Base addresses for cards are described as >1xxx, you can't shift that left or you lose the 1. But lots of software libraries talk about remembering to shift your bit... so that must mean using a counting by 1s mental model.

 

So, if I use the machine code above, where >A30C comes from R12 R12 Add (Yoda assembly ), and I want to address cru-bit 0 with cru-base >1F00, then I suppose I load R12 with >1F00 / 2 ...

 

That seems pretty weird to me. Because I'm playing with hardware, and really care about the individual address lines and their state, trying to decode the cru-addressing.

 

Is that where this shifty (pun) convention came from... Software side wanting to think of it as specifying 1 of 4096 cru-bits, counting by 1s?

 

I believe I can skip the doubling of R12 if I set R12 to the state I want the address lines to be in.

 

-M@

 

Comparing how the CRU works at software and hardware level:

 

Load R12 with the CRU base address (such as >1F00). This is the address presented on the address bus A0 - A15 for CRU operations. A0 - A2 are always 0, and A15 is ignored. Your CRU hardware address decoding needs to work with the address in R12.

 

With the (assembly) TB, SBO and SBZ instructions, you specify a signed offset. At the hardware level, this offset is shifted left one place, hence doubling it, and added to the CRU base address in R12, and that value is presented on the address bus. As your CRU device is not connected to A15, but to A14 up to A10 (or whatever), the device is also in effect 'shifted left one place' and sees the original offset specified in the CRU instruction. So the CRU device documentation talks about the functions of CRU bits 0, 1, 2, ... (counting by 1's), which match the offset you specify in the CRU instructions.

Edited January 3, 2017 by Stuart

[apersson850]

All this is of course because as far as the TMS 9900 is concerned, A15 doesn't exist physically. There are only 15 address pins on the device, not 16. When you address a byte in memory at location >1234 or >1235, the CPU will actually do the same thing from a hardware point of view. It will read the word at >1234, then present the left or right byte to you. The fact that the hardware in the TI 99/4A is designed to do actual byte addressing doesn't change how the CPU looks at it.

When it comes to CRU bits, as they are hardware devices, you can't connect them to a pin that doesn't exist. Hence these two code examples are equivalent.

LI  R12,>1F00
SBO 1

LI  R12,>1F02
SBO 0

[+mizapf]

I just uploaded two more WAV files to the WHTech server at Cassettes/Mini_Memory:

• Lines_Mini_Memory_edited.wav: The two WAV files on the server were not usable in MAME, since they are WAV files with floating point values. This version here has been edited by me with Audacity; I converted them to Mono, changed the values to 16 bit integer, and applied some volume leveling. Now this file can be read in MAME with no problems.
• Lines_Asm_remastered.wav: From MAME, I saved the file again, so we get a "clean digital" version that is hopefully also usable with real systems. At least it is ensured that all bits are preserved.

If you wonder how to work with this in MAME:

 

Either start MAME with the command line argument -cass1 Lines_Asm_remastered.wav or insert the WAV file in slot cassette1 in the File manager. Go into the OSD menu, Tape control, and stop the tape for now (because the tape play will start immediately).

 

Press a key, start EASY BUG, press another key to close the help screen, then press L (for load). Use the Tape control to press Play when requested. Then, after 1:14 min loading time, a DATA OK should appear. Go to Tape control and press Stop.

 

Exit EASY BUG with the QUIT key combination.

 

Enter MINI MEMORY, go to 2 RUN, type LINES and see the Lines demo. Exit with QUIT. Go again to 2 RUN, type NEW, and the Line-by-line Assembler is launched. If you enter OLD, you can continue with the old program.

 

Links:

ftp://ftp.whtech.com/Cassettes/Mini_Memory/Lines_Mini_Memory_edited.wav

ftp://ftp.whtech.com/Cassettes/Mini_Memory/Lines_Asm_remastered.wav

[+acadiel]

I just uploaded two more WAV files to the WHTech server at Cassettes/Mini_Memory:

• Lines_Mini_Memory_edited.wav: The two WAV files on the server were not usable in MAME, since they are WAV files with floating point values. This version here has been edited by me with Audacity; I converted them to Mono, changed the values to 16 bit integer, and applied some volume leveling. Now this file can be read in MAME with no problems.
• Lines_Asm_remastered.wav: From MAME, I saved the file again, so we get a "clean digital" version that is hopefully also usable with real systems. At least it is ensured that all bits are preserved.

If you wonder how to work with this in MAME:

 

Either start MAME with the command line argument -cass1 Lines_Asm_remastered.wav or insert the WAV file in slot cassette1 in the File manager. Go into the OSD menu, Tape control, and stop the tape for now (because the tape play will start immediately).

 

Press a key, start EASY BUG, press another key to close the help screen, then press L (for load). Use the Tape control to press Play when requested. Then, after 1:14 min loading time, a DATA OK should appear. Go to Tape control and press Stop.

 

Exit EASY BUG with the QUIT key combination.

 

Enter MINI MEMORY, go to 2 RUN, type LINES and see the Lines demo. Exit with QUIT. Go again to 2 RUN, type NEW, and the Line-by-line Assembler is launched. If you enter OLD, you can continue with the old program.

 

Links:

ftp://ftp.whtech.com/Cassettes/Mini_Memory/Lines_Mini_Memory_edited.wav

ftp://ftp.whtech.com/Cassettes/Mini_Memory/Lines_Asm_remastered.wav

 

 

Woot, thanks for getting it to work with MESS! The only thing I did to test was playback from a PC to a real system; I wasn't aware that MESS needed specific values for the .wav files

[+mizapf]

It seems as if the problem was not the float encoding (it is 16 bit integer, actually) but the stereo recording. Audacity said something about float encoding, but this just referred to the internal representation during editing.

[+InsaneMultitasker]

 

So, if I use the machine code above, where >A30C comes from R12 R12 Add (Yoda assembly ), and I want to address cru-bit 0 with cru-base >1F00, then I suppose I load R12 with >1F00 / 2 ...

 

-M@

I recall a conversation with Bill Sullivan 5-6 years ago that touched on Forth and some CRU "doubling" confusion he was working through.

 

The "problem" at that time was found in the TI Forth implementation of SBO/SBZ (and perhaps the others that Lee points out in his fbForth excerpt) where those routines were/are hard-coded to use CRU offset 0. R12 must therefore point to the base + offset, which can be done by halving the 'standard' address, i.e., >1F00 / 2, and adding the signed offset to the result. When that combined value is passed to Forth's CRU implementation, R12 is doubled, arriving at the proper base+offset for the instruction. Bill did not want to change this implementation for compatibility purposes; I suspect similar reasons hold true for other Forth implementations.

Edited January 3, 2017 by InsaneMultitasker

[+Lee Stewart]

I recall a conversation with Bill Sullivan 5-6 years ago that touched on Forth and some CRU "doubling" confusion he was working through.

 

The "problem" at that time was found in the TI Forth implementation of SBO/SBZ (and perhaps the others that Lee points out in his fbForth excerpt) where those routines were/are hard-coded to use CRU offset 0. R12 must therefore point to the base + offset, which can be done by halving the 'standard' address, i.e., >1F00 / 2, and adding the signed offset to the result. When that combined value is passed to Forth's CRU implementation, R12 is doubled, arriving at the proper base+offset for the instruction. Bill did not want to change this implementation for compatibility purposes; I suspect similar reasons hold true for other Forth implementations.

 

Hence my comment in the excerpt you mentioned:

 

“In the author’s opinion, these words should emulate the behavior of their TMS9900 Assembler counterparts; but, rather than break old TI Forth code by changing their definitions, ...”

 

...lee

[+jedimatt42]

The Ti Forth and fbForth implementation points out what apersson850 illustrated... I can see how TI was trying to be helpful with the sbo/sbz instructions taking a bit count offset. It is cool that it is just about composing the right value on the address lines, so there are, as always, more than one set of instructions that get you there.

 

I've been using the forth approach... in fbForth, I define my own word and skip the maths. So, I let the SBO word in TI forth be (unloaded as it is), and I don't bother with a ( addr bit -- ) contract cause I only care about thinking of the address lines.

 

CODE CRUON C339 , 1D00 , NEXT,
CODE CRUOFF C339 , 1E00 , NEXT,

So if I want bit 1, it is on me to put the address on the stack first with bit one incorporated... 1F02 Or since I'm just trying to get bit 0 captured by a GAL16v8a, typing 1F00 CRUON is really straight forward. And typing in the CODE to define the word is pretty painless.

 

I can easily then define a word to toggle it off and on in a loop... doing things like poking and peeking memory is crazy easy too... and writing loops to do this and allow observation with measuring instruments is very handy... No build/deploy/reboot in the development process. Cartridge based forth for the win!

 

A very happy camper am I.

 

-M@

[+Lee Stewart]

I do not remember what build of fbForth 2.0 you have, but you can avoid using , (comma) in later builds by using CODE: ... ;CODE as follows:

HEX
CODE: CRUON C339 1D00 ;CODE
CODE: CRUOFF C339 1E00 ;CODE

...lee

[+jedimatt42]

I have kept it up to 2.0:8. I've been so busy building memory cards I hadn't burned 2.0:9 yet. Now sounds like a good time to do that.

 

 

-M@