• Please review our updated Terms and Rules here

IBM 5110 initial info

Your investigation of retrieving the non-executable ROS reminds me of my own experience with a similar effort, which I wrote about here:

You'll notice a similar table to the one you've made for the BASIC/Common ROS. I don't know why there is the repetition that we both observe, but as I say in the writeup, I feel like a clever person could work out the reason behind the behaviour.

With regard to your earlier remarks:


- Good thinking about using the composite signal from the back of the monitor. I remember now that I investigated this option, although at the time (and even today) the only capture device I had to hand is a NeXTdimension board in a NeXT computer. For some reason, photography seemed simpler.


- The "tape status" register --- per the 5100 MIM, the "tape status byte" lives in the "Common Language Control Area" (PDF p.98). Unlike the registers (which are memory-mapped to address $0000 and up), I don't think this byte is part of the hardware in the same way --- instead, my guess is that it's an ordinary memory location maintained by software that the Executable ROS loads and sets up in RWS from the non-executable ROS.

My point in saying this is that you might need this software to be running in order for that byte to be useful. What does "running" mean? Well, it could mean a couple of things. It could be that any change to the state of the tape triggers an interrupt that will cause the PALM to run that software and update the byte. Or it could be that that byte only changes if another program calls that software, as the APL interpreter would when executing the `)LIB` command, for example.

TL/DR: Don't be too disappointed if that byte doesn't change even if you manipulate signals on the I/O port. Consider using a specially-written PALM program to poll the tape hardware directly.


- I don't remember BX and can't recall what it means. It might not be in the 5100, or just as likely that I missed it. It's nice to know about the machine check jumper.


- Don't you have two 16K RWS cards? Remember the diagram you shared much earlier: each card only occupies half the slot. (It looks like the 5110 uses a single plastic bracket to hold both cards.)

Here's a little video of some of the 5100's 8K RWS cards. I made it as part of this video.
 
Nice video!

Yes - you're right, its two 16K cards side by side. If that sample copies only "0x4000" chunks, yeah a full 16K should still fit for me (consuming 0x1000 to 0x5000 in the RWS, 4K to 20K). So my mix up, no 12K limit - I was just excited that things were matching so well at all. BTW, I found HxD as a useful hex editor under windows - to preview the existing ROS bins in 16 columns, just like the 5110's DCP assembly editor "alter-er". Had HxD on the side while I was spot checking all around on the 5110's with the DCP D (display) command.


I took a first stab at trying to make sense of the ROS CRC checks from the ASM. Hadn't figured it out yet (like how it knows what the CRC checksum total should be - those should be constant laying around somewhere, no?). In the Commons ROS, I wondered if that single byte difference I found upfront is related to a CRC checksum difference (due to the last ~500 bytes being quite different, then you'd expect the CRC total to be different).


Much to explore :)
 
I never bothered trying to understand the CRC code that the executable ROS uses to check the non-executable ROS --- I just converted the assembly language routine to Python without figuring out how it works. You can see it here:

I think the single-byte difference just indicates that one of the addresses where you found the data is not a valid address, and that you "get" the data from somewhere else owing to the way the non-executable ROS is wired.

You can see that I encountered a single-byte difference when reading part of my 5100's BASIC/Common ROS as well. It's in the table here:
 
Wow, DAY 1: I now have the 5110 emulator running in the MSVC debugger. I took out the X11 (GUI) stuff for now and found a Windows wrapper to the pthread content. And thankfully the code already had provisions for running on Intel LITTLE_ENDIAN !

The only other issue was figuring out the font codes used by the 5110 display. It's not standard ASCII (especially since it has to accommodate the "weird" symbols used by APL). (FontForge to the rescue, since Thomas A. Fine (of Harvard Edu) already mapped them out and defined them in a BDF file (I think I recall them listed in one of the manuals also) -- but without X11 support, I'm just using a standard console font, so I mapped back to only the main printable characters for now).

Good start. Next is to stream inputs from a file (no plan for an interactive console), and start exploring what's going on here. Easier said than done, since I suspect I'll need an input parser to handle things like CTRL-chars, and another mapping of ASCII-file inputs into native keyboard scan codes.

EDIT: I'm just printing the 16 rows of the screen back to back. Those familiar with the 5100/5110 or the emulator will be familiar with the "ABCDEF..." bootup ROS checks, followed by the "READY" prompt and RWS (RAM) space remaining at the bottom of the screen. That's all getting shown now, based purely on parsing the 5110 ROS binaries..... Oh, you know, what if we plug the 5100 ROS binary into there? I'm not ready to try that just yet, but I think there is a chance it will work with very little effort.


IBM5110_vs2010_first_working.jpg
 
Last edited:
Impressive! I don't know enough about other differences (I'd guess hardware addresses may differ here and there), but I think the 5100 and 5110 character maps may differ. For starters, the 5100 has no lower-case letters in its display font, while the 5110 does.
 
DAY 2 of studying the 5110 emu source (I'm on travel and just get a couple hours in the evening to look at it). I like Linux, but I'm trying to bring this over to the Wintel platforms (since I just like the VS integrated debugger).

Keyboard input scripting is working now!!! I wrote a little parser to control pressing "normal" keys, or with CMD or SHIFT variations. Then I realized I had to throttle it -- as it is actually possible to type too fast.

and THEN - I used this to enter the DCP mode during startup! That was another timing issue - if you hit CMD-ATTN too early during the ROS checks on power up, other weird stuff happens (or nothing at all). If you take too long, then the command ROS has started up and you missed your chance to enter DCP (DCP is the built in diagnostic, but it is also access to the built in assembler). So it was a balance between waiting long enough, but not too long (just like on the real H/W).


I see the key codes in the 5110 manual (MIM 2-36), so I understanding that mapping between the host keyboard and IBM 5110's onboard. I was also able to enter some numbers and letters, so I can setup the parsed input script to bang out any desired keyboard sequence.




WHAT THIS MEANS IS.... we could load programs using the keyboard! (like a custom OS that had customized handing of the I/O ports -- or even the Ball Bounce Program could not be loaded via a script, if we tethered into the keyboard pins). I'm not sure what the "bytes per second" speed would be on that, but I think it would beat 110baud at least, maybe 300-1200baud even. I'm not sure if I'll try that - but if a day comes when we want to enter an extensive PALM assembly (something way over 500 bytes), this could be a way to do it.


This doesn't help me yet in an alternative and more automated way to extract the Executable ROS - but I'm still exploring.


Couple things in the emulator:

(1) confirmed "bas_ros.bin" is not used, so still a mystery what that is. (the last 8K of it are actually blank, but the first 16K of it are identical to the non-executable BASIC.. in any case, we put it to the side for now)

(2) examining the OP(code) line of code... there is a ">> 1" at the end that suggests to me that the (non-executive) executable ROS (common, language, async, feature) can't be larger than 32K. In this IBM 5100 system the "register file" is the first 128-bytes of RWS/RAM (32-bytes for each of 4 interrupt levels), and I think the program counter is the first register (of each level). [ but the NON-executable ROSs -- that represent the System/3 and System/360 code, those can be way larger than even 64K, so I'm still trying to understand how those work - it's sort of like a 16-bit machine is being setup to emulate a 32-bit machine? {or maybe 20-bit} which that's certainly possible; tired now for today :) someone mentioned bank-switching I think -- but I don't think so in this case, since the "non-executive" stuff mean its a different set of opcodes than the native processor -- that seems wicked smart to me, to write such an emulator without a screen editor or debugger? I wonder how much of the common and language ROS was ready by the 1973 SCAMP prototype? we'll have to open up the one in the Smithsonian and extract its ROS's someday :D I'd just like to see photos of it opened, see it's A1 board and cards ]

Refence to code go get the next opcode instruction:

OP =
((mode[level] == MODE_RWS) ?
// "true", the current level is in RWS MODE
RWS // next instruction always written to beginning of RWS (language ROS must be handling that)?
:
// "false", the current level is not RWS MODE... examine further...
(level ?
// "true" (1,2,3), force executive ROS
ExecROS
:
// "false", index into the designated ROS for level 0
curr_ros))[curr_regs[0] >> 1]; // does >>1 imply a ROS can't be larger than 32K ? (this limitation does not apply to non-executable ROS)







IBM5110_vs2010_keyboard_input.jpg
 
Last edited:
This is an interesting idea --- using the keyboard interface to type in programs. I like it!

BTW, by "built-in assembler" --- is this just the hex editor? I didn't think the 5100-series had an assembler in ROM, but maybe the 5110 is more elaborate in its offerings.

About addressing. For the non-executable ROS, the address that you supply to the I/O system that moves the data around is a 16-bit word address, not a byte address. So a non-executable ROS can be 128k without any need for banking.

For the executable ROS I suspect that it's something similar, given that PALM instructions and immediate data is always 16 bits. I'm guessing the shifting you're seeing might be something to do with that.
 
Yes, I think we could inject keyboard scancode signals in an un-intrusive way (i.e. just connect to the pins on the bottom side of the Z4 connector? Don't have to splice into existing keyboard cable; or alternative: unplug the existing cable and craft our own "auto-keyboard" input, but making/sourcing the edge connector won't be easy - or as mentioned, just access the pins from the other side of the connector, I think they go all the way through the A1 board - not home atm to check, but these are reference images for the area I'm talking about).

1646827149805.png


And you're right, DCP has a memory editor, not an assembler that accepts mnemonics. So yes, I meant "editor" rather than "assembler", nothing more fancy in the 5110 ROM for that.



Today all I got time to do was add a parser command Q (sequence), to help make inserting plain-text keyboard key press sequences easier. This way you can express things in "normal ASCII" (which I should probably call it that - A for ASCII instead of Q), and it will translate that sequence content of ASCII into the corresponding scancodes (and automatically puts a little delay between each entry of the sequence -- that delay lets the processor run to absorb processing the actual keystroke, it gives it about 50-100 cycles to do that, or however many it can do in a couple screen 60hz refreshes).

Using this made it a lot easier to bang in the Ball Bounce program from a script :) Here is an example below, where on the left you have the Q sequences (corresponding to the PALM assembly code) in the command text file, which are parsed and then "typed" into the emulator. The D (DELAY) commands aren't necessary, but I'm using them just as a placeholder for comments (in this case, the comment is the address the next sequence should be entered at - just as a reference point). (format is "D n any-comment" = DELAY n screen refreshes, approximately).


1646826616104.png


Then to run it, use these commands:
N 9 ATTN <- press the ATTN key to go back to the DCP console (9 is translated to scancode 0xB6)
Q 0 BR 0B00 <-- sequence in typing "BR" (branch run) and the address to run (translates all that ASCII to appropriate scan codes)
N 36 <-- press the EXECUTE key (gets translated to scan code 0xB2)

[ S command is used to press keys with SHIFT held, similar for C used for CMD state ]

More to come, work in progress :)
 
Incorporated pdcurses into the project to make it easier to show multiple-windows of things at the same time.

The "display" on the left, the keyboard parsing scrolls in the middle, and added a hex-memory dump on the right. I'll add color later to better highlight these separate areas.

It's more fun to see it "live" so I'll upload a video of that:




Next thing: since the first "register" is the program counter, maybe I could add an "on the fly" disassembler. Then add a software version of the "STEP SWITCH" so we could go instruction by instruction to see the effects.

But this is helping to get a better understanding of how the different levels swap between RWS and ROS's (see the sample below, the level 0 program counter register is at "0BDC" (DC 0B at the start of the dump), which is precisely in the region of the sample program (that started at 0x0B00). The "hex dump" here isn't replicating the hardware-switch on the IBM5100 - which that one has a funky what of showing the 16-bit register values: it shows them vertically, which is a good way to save horizontal screen space, but makes it harder for me to decipher them on the fly. So the emulator helps present that in a more natural way (IMO).


1646914174113.png
 
Well, looks like this became my Spring Break project for 2022 :) Couldn't help it, made it interactive and can single cycle step clear from the beginning of BUP (startup).

Christian included several BASIC samples with this EMU package - none of them actually work on the IBM 5100. But the easiest one to adapt that I found was the one called salvo1.bas (a Sink-my-Battleship type of game, where the computer does make random guesses to sink your own). Some limitations of IBM 5110 BASIC: (1) no ! (exclamation mark) - it has "?" but not "!", mostly an issue just for print strings that contain "!" or ' apostrophes, (2) multiple BASIC statements can't be compounded using ":" colon, (3) lines can be over 64 columns, (4) the 5110 does have RND(n) to init a random seed, but to get a RND value use "RND" itself (no parans) assigned to a variable.

Pretty neat that his modified version of salvo1.bas is actually playable now, on the 5110 (and probably the 5100) :D

Lots of interesting things observed - (1) like at the end of each BASIC statement that is executed, the system switches back to EXECUTIVE ROS (which makes sense - to handle things like scrolling the screen, monitor for ATTN to suspend the run and resume it with "GO"). (2) To reach the bootup blinking cursor prompt takes about 2 million CPU cycles, (3) the BUP sequence is about 170,000 CPU cycles before the ROS's start getting initialized and checked, (4) it takes ~10,000 instructions just to blink the cursor!!

it's all functional, including even the tape support (Christian included a sample CSF in both DSK and TAP formats). Christian also included a PALM disassembler .c in his EMU source - that compiles very easily. With that, I might be able to offer an "on-the-fly" PALM OP disassembler right in the emulator. I wrote a MIPS emulator decades ago, and my C is still quite rusty -- we'll see. But at least I think there is enough here to help me figure out the ROS CRC stuff now :D

I'll get this branch going in git eventually - some code cleanup to do first. And I tried to make it work with the 5100 ROS - conceptually the piece parts are there (as far as PALM opcode support), but it's going to take a bit more work to sort out.




demo2preview.jpg
 
Very cool work --- it's so interesting to learn about all of these inner workings. I hope you are collecting this information somewhere :)

But the 51[012]0 definitely do have the exclamation mark. You just have to compose it.
Type ' (single quote). Then press the back arrow. Then type . (period/full stop). That's it!
Not all pairs of characters compose in this way, but some do. It's one of my favourite quirks.

This odd form of entry is almost surely there for the sake of APL, and for making the user experience feel similar to using a hard-copy terminal that uses a typewriter mechanism. Despite all of the symbols on a standard APL keyboard, they're still not enough to type all of the functions and operators APL has. To type "⍉" (transpose), for example, you first have to type "○" and then back up and overstrike it with a backslash "\".

You get this kind of character composition "for free" with a hard-copy terminal, but you have to emulate the experience somehow when you have a glass-screen character display.
 
Also, as far as BASIC limitations go... how long can a string be?
According to the manual, there are three different ways of handling a string. Character constants have a maximum of 64 characters. Character variables have a maximum of 255 characters. Character arrays look like they could be 9999 by 9999 for a two dimensional array with each element having 256 characters but I don't believe the memory is available to actually get anywhere close to that in practice. 25 GB might be a bit impractical even today.
 
Last edited:
@stepleton oh my, I missed that about the "!", thanks! I had a test program to cycle through 0-255 and render all the "fonts" the display was capable of -- which I noticed there are lower case characters, underscore versions of characters, and lo and behold at index 219 there is "!". But on the input side, I just focused on what the labels on the keys were, and didn't consider that a combination of keys led to getting interpreted as the ones that were "missing" (from the keyboard labels). Cool :) And the emulator even supports that as well ( ' left arrow . = ! ). I'll see about having the PC keyboard ! ASCII interpreted into that sequence automatically.

Also, regarding BASIC strings - misspoke in my haste, I meant "can not" be over 64 characters (or really about 58 characters). But to clarify: I mean from a terminal limitation (you'll use about 7 characters just indicating something like "10 A$=" to start, or "20 PRINT"start...). Once you get to column 64, then it just wraps back over to column 1, destroying the first part of your row. So for scripting BASIC program inputs, you can't really have a line with 64 characters (minus whatever the code prefix is, like line numbers and BASIC commands). HOWEVER, internally, maybe a longer string could be constructed (with DATA statements??) I'm not sure if there are any CONCAT commands, or if something like C$ = A$ + B$ would work, nor did I see anything like CHR$(54) to insert special characters into the string. Although I'm not sure how such a long string would be printed out (wrapped to next line or just wrapped over to the current line?) - guess we can try it :D


NOTE: before I forget - even in Norbert's notes, he found the HOLD button buggy (in the emulator). It seems to work fine while in the EXECUTIVE mode, but during executing a BASIC program indeed the HOLD button doesn't seem to want to resume (it works fine on the real hardware in both cases, so it's not a ROS issue).


In my own version of the emulator, there are still some issues: (1) LOAD isn't working (I'm hoping it is just some missing conversion due to the Intel little-endianness), (2) the E80 tape access is orders of magnitude slower than the D80 disk access -- maybe that's reality? it's cute you have to type REWIND even after doing a UTIL DIR on the tape! (3) release builds are halting now and then - not all the time or consistently, but enough to be irritating (and not a crash, the OPcode just goes funny - maybe a mutex issue, but the debug build doesn't seem to have this issue). (4) the release build is so fast, you can't really issue a CMD-ATTN during the ROS CRC checks to enter DSP before hitting the language console [ you can using STEP mode, since the last key you issued will end up "pressed" when you resume ]. But I learned you can access that DSP from the "language console" at any time with a slightly different key combination (and then exit it, to resume back to your language programming).


But my next goal is to focus on this CRC business. I don't think I can contrive the Executive ROS to "output itself", but as was suggested: if the CRC result of Christian's Executive ROS matches my own Model 2's Executive ROS, and I can view that result, then that should equally answer on if they are identical or not.




I haven't yet really bothered with the APL symbols. They can be input using the scripted input (as it can index into any key combination, including with SHIFT or CMD state changes - I have an Excel spreadsheet prepared to know which ASCII PC-keyboard index translates to which key, and MIM 2-26 has the hex scan codes {and yes the codes are quite different for the 5100}, but it doesn't have these special "key combinations"). But translated from the PC ASCII keyboard input, I don't have any clean translation to APL symbols. That whole concept intrigues me, since for years I've thought: why worry about high-level language syntax A vs. syntax B - instead focus on the INTENT of what you want done. The high level languages get boiled down into an Abstract Syntax Tree, where the nodes are just that - like a "FOR LOOP" node, decorated with the typical set of parameters for that type of node. So without literally typing "f" "o" "r" instead you plop down a (FOR) construct, and populate the node parameters accordingly. BUT, it's not that simple: nothing beats the simplicity of a notepad.exe like data grid (for implementing and porting to new systems), and so programming is just going to have to be held to that format (of shoveling ASCII characters around). But I've wondered if VR might be used to change that? (e.g. in VR, you select from a palette of APL symbols, place them into your program-tree... something like that) Anyhow, entirely different subject...



Also, I'm still a little confused about the Common ROS. Even in the emulator, it is marked as an "nx" ROS (non-executable). My understanding is "NX" is anything that is NOT PALM opcodes. And any of the "NX" ROS's can be up to 128K (64K by 16-bit instead of 8-bit), as stepleton pointed out before. But if APLNX is System/360 codes and BASICNX is System/3 codes, then what is the Common ROS NX ? maybe it's a hybrid of both, as a middle-layer to help translate things like disk/tape/IO access in a common way across both APL and BASIC?)



EDIT: one last thing! :D Another modification to my "5100-compatible" salvo.bas is I exercised GOSUB to redraw the board between turns - the original version didn't have this. I wanted to make sure GOSUB still work in that version of BASIC, and I think it helps remind players what to do in entering their next firing commands. Could add things like marking slots that were already tried, or confirmed hits.
 
Last edited:
The concatenation symbol for 5110 BASIC is a pair of vertical lines. I think that is entered with Shift-M followed by a second Shift-M. See page 72. For a more complex method, page 71 shows how to use STR to change part of a string. If one knows where the current string ends, adding new data past that point requires starting the STR at that point.

A minor warning, any character variable not given a length through a DIM statement will store 18 characters.
 
According to the manual, there are three different ways of handling a string. Character constants have a maximum of 64 characters. Character variables have a maximum of 255 characters. Character arrays look like they could be 9999 by 9999 for a two dimensional array with each element having 256 characters but I don't believe the memory is available to actually get anywhere close to that in practice. 25 GB might be a bit impractical even today.

Serves me right for asking a leading question without knowing where it leads. The 5110 BASIC is clearly more advanced; on the 5100, I'm pretty sure that character variables can only ever be 18 characters, no exception, and DIM is only for arrays. I consider this to be a pretty annoying limitation, which is why I brought it up when we were talking about limits! Although I should try the character array dimensioning syntax and see what happens: DIM A$255 I think it would be.

The high level languages get boiled down into an Abstract Syntax Tree, where the nodes are just that - like a "FOR LOOP" node, decorated with the typical set of parameters for that type of node. So without literally typing "f" "o" "r" instead you plop down a (FOR) construct, and populate the node parameters accordingly.

I think the ZX80 and ZX81 worked that way; keywords mapped onto the keys themselves.

I had a test program to cycle through 0-255 and render all the "fonts" the display was capable of -- which I noticed there are lower case characters, underscore versions of characters, and lo and behold at index 219 there is "!".

For the 5100, you can find a character table on PDF page 336 in the Maintenance Information Manual. I was surprised that I couldn't find one in the 5110 MIM, which seems shorter overall. Anyhow, ! on the 5100 is at 0x60.

One tricky thing that you might find in your study is that the computer could use two character encodings at once! I think APL may use something called "Z-code" (see PDF page 327) which then gets translated to the actual character map that the display uses. It might be the case that BASIC's character set is similarly translated, although I have no evidence of this.

The 5110's own APL character mapping is on page 239 of the APL reference. Note that you have two forms of !, "QUOTE DOT" at decimal 49, and "ALTERNATE SHRIEK" at decimal 242.
 
Ah, PRINT strings can be over 18 chars, that was the only string I was thinking of :)


As for X$ type strings, yes that's something else. Some odd things while experimenting (on the 5110 hardware with BASIC):
DIM A$(50) works
But if I do DIM A$(50) again, it gives ERROR 661 (and likewise for any subsequent DIM against A$, smaller or larger). That's odd, seem you just get 1 chance to DIM a string variable?

Then verified what the examples say:
I did A$='12345678901234567890' (20 characters)
And the terminal looks like it accepts that, no problem. Except, when I then do PRINT A$, I only get the first 18 characters! (the "90" at the end are cropped off)

DIM A$(50)
A$='12345678901234567890'
12345678901234567890
PRINT A$
123456789012345678


This is on the 5110 model 2 (and the emulator based on model 1 ROS). So - I'm not sure what the actual max length of a BASIC string variable is :) Seems like 18, like the 5100 (except in the case of PRINT literals).

If I can do
PRINT '1234567890123456789012345678901234567890' (40 chars, and that works as expected)
I had assumed I could also do
A$ = '1234567890123456789012345678901234567890' (but that doesn't seem to be case!!)

@krebizfan I couldn't find what you meant with the compound statements with double SHIFT-M. I do see on the physical 5110 keyboard, SHIFT-M is a vertical bar |. I couldn't see which PDF of pages you were meaning. I tried "PRINT A||PRINT B" without success.

One way I found to "concat" print outputs, was doing something like: PRINT A,A*2,B (it pads each , by 20 chars)
But if you do PRINT A;A*2;B (semicolon instead of ,) it pads by 6 instead of 20 (just discovered by trial and error, didn't see it documented)

To compound something like "A=5:B=6", colon didn't work for me (on the 5110). Is something the double vertical bar can support? (I tried some variations, but no success)

Also 5110 BASIC doesn't seem to support the LET keyword.


 
Ah, PRINT strings can be over 18 chars, that was the only string I was thinking of :)


As for X$ type strings, yes that's something else. Some odd things while experimenting (on the 5110 hardware with BASIC):
DIM A$(50) works
But if I do DIM A$(50) again, it gives ERROR 661 (and likewise for any subsequent DIM against A$, smaller or larger). That's odd, seem you just get 1 chance to DIM a string variable?

Then verified what the examples say:
I did A$='12345678901234567890' (20 characters)
And the terminal looks like it accepts that, no problem. Except, when I then do PRINT A$, I only get the first 18 characters! (the "90" at the end are cropped off)

DIM A$(50)
A$='12345678901234567890'
12345678901234567890
PRINT A$
123456789012345678


This is on the 5110 model 2 (and the emulator based on model 1 ROS). So - I'm not sure what the actual max length of a BASIC string variable is :) Seems like 18, like the 5100 (except in the case of PRINT literals).

If I can do
PRINT '1234567890123456789012345678901234567890' (40 chars, and that works as expected)
I had assumed I could also do
A$ = '1234567890123456789012345678901234567890' (but that doesn't seem to be case!!)

@krebizfan I couldn't find what you meant with the compound statements with double SHIFT-M. I do see on the physical 5110 keyboard, SHIFT-M is a vertical bar |. I couldn't see which PDF of pages you were meaning. I tried "PRINT A||PRINT B" without success.

One way I found to "concat" print outputs, was doing something like: PRINT A,A*2,B (it pads each , by 20 chars)
But if you do PRINT A;A*2;B (semicolon instead of ,) it pads by 6 instead of 20 (just discovered by trial and error, didn't see it documented)

To compound something like "A=5:B=6", colon didn't work for me (on the 5110). Is something the double vertical bar can support? (I tried some variations, but no success)

Also 5110 BASIC doesn't seem to support the LET keyword.


Is your syntax correct? You need to use " " not ' '. Shouldn't A$ ="1234567890123456789012345678901234567890" not A$='1234567890123456789012345678901234567890'
 
DIM A$(50) makes an array of 50 strings each 18 characters long. To make a 50 character long string requires DIM A$50. DIM A$50(25) makes an array of 25 elements each 50 characters long. Yes, the BASIC works a bit differently from other BASICs and the various implicit values like the default member of an array are not documented as far as I can find.

It appears that after DIM A$(50) that referring to A$ with no array element is equivalent to A$(1) the first element but that may not hold in all cases.
 
Back
Top