Wednesday, February 14, 2024
Notes from an overheard conversation from a car attempting a right turn
“Oh! Now what?”
“Sir, see the lit sign up there? You cannot turn right.”
“But did you not see the car right in front of me turning right?”
“Sir, if a person jumped off a bridge, would you follow?”
“Yes.”
“You must be very smart then.”
“And selective enforcement of the laws leads to distrust of the police.”
“Sir—”
“Oh look! The ‘No Right Turn’ sign is off now! Gotta go! Bye!”
“I don't think it's wise to taunt the poice like that.”
“Down with the Man! Power to the people! Yo!”
Sunday, February 11, 2024
An extensible programming language
A few days ago I wrote about adding a factorial operator to my assembler, and I noted that I knew not of any other languages that had such a feature. So imagine my surprise as I'm reading about XL (via Lobsters) and the second example is factorial! Not only that, but that was an example of extending the language itself! The last time I was this excited about software was reading about Synthesis OS, a JIT-based operating system where you could create your own system calls.
How it handles precedence is interesting. In my assembler, I have left or right associativity as an explicit field, whereas in XL, it's encoded in the precedence level itself—even if its left, odd if its right. I'm not sure how I feel about that. On the one hand it feels nice and it's one less field to carry around; on the other, being explicit as I did makes it clear if something is left or right. But on the gripping hand, it sounds like matching precedence on a left and right operator could lead to problems, so I still may have an explicitness problem.
But I digress.
It's a very simple language with only one keyword “is” and a user-definable precedence table. The parser generates a parse tree of only eight types, four leaf nodes (integer, real, text, name (or symbol)) and four non-leaf nodes (prefix, infix, postfix and block). And from there, you get XL.
This is something I definitely want to look into.
Wednesday, February 07, 2024
Instead of “write-only memory” assembly support, how about floating point support?
You might think it odd to add support for floating point constants for an 8-bit CPU, but Motorola did development on the MC6839 floating point firmware for the MC6809, an 8K ROM of thread-safe, position-independent 6809 code that implements the IEEE Standard for Floating-Point Arithmetic. It was never formally released by Motorola as a product, but from what I understand, it was released later under a public domain license. At the very least, it's quite easy to MC6839 find both the ROM image and the source code on the Intarwebs. So that's one reason.
Another reason is that the Color Computer BASIC supports floating point operations, and while not IEEE-754, as it was written before the IEEE-754 standard become a standard, it still floating point, and there are only minor differences between it and the current standard, namely the exponent bias, number of fractional bits supported, and where the sign bit is stored. It really comes down to some bit manipulations to massage a standard float into the Color Computer BASIC float format. There are some differences, but the differences are small (literally, on the scale of 0.0000003) probably due to parsing differences, and small enough that it should be “good enough.” Especially since the Color Computer BASIC float format doesn't support infinity or NaN.
So if you specify a backend other than the rsdos backend,
you get IEEE-754,
and if you do specify rsdos as a backend,
you get the Color Computer BASIC float format.
And yes,
I added support for floating point expressions
(but not for the test backend—I'm still thinking on how to support it),
and one interesting feature I added is the factorial operator “!”.
Factorials are used in Talor series,
which the Color Computer BASIC uses for the sin() function,
so I can literally write:
; Oh! '**' is exponentiation by the way! taylor_series .float -((2 * 3.14159265358979323846) ** 11) / 11! .float ((2 * 3.14159265358979323846) ** 9) / 9! .float -((2 * 3.14159265358979323846) ** 7) / 7! .float ((2 * 3.14159265358979323846) ** 5) / 5! .float -((2 * 3.14159265358979323846) ** 3) / 3! .float 2 * 3.14159265358979323846
and have it generate the correct values. I personally don't know of any language that has a factorial operator (maybe APL? I don't know).
I think I'm having more fun writing the assembler than I am writing assembly code.
Tuesday, February 06, 2024
Okay! I'll answer your question, LinkedIn. Also, Orange Site! Orange Site! Orange Site!
Today's “you're one of the few experts invited to add this collaborative article” from LinkedIn is “How do you become a senior application developer?” My answer? Stay in a programming job for three years. Boom! You're a senior application developer. I know, I know, that's a big ask these days when everybody is jumping ship every two years. But hey, if you want to be a “senior application developer,” you got to make sacrifices.
Oh, and the title to today's post? I found out that LinkedIn really liked when I mentioned the Orange Site in the title of my post. Almost two orders of magnitude more. So I'm doing a test to see if I can game the system there.
So you want to amplify my SEO
- From
- Krystal XXXXXXX <XXXXXXXXXXXXXXXXXXXX@gmail.com>
- To
- sean@conman.org
- Subject
- Amplify Your SEO with Strategic Link Inserts
- Date
- Wed, 7 Feb 2024 01:16:35 +0300
Hi Content Team,
It’s Krystal XXXXXXX here from Next Publisher, your next potential partner in digital storytelling. We're thrilled about the idea of featuring both guest posts and link insertions on your dynamic website.
We would like to know your fee structure for hosting guest posts and link insertions. Our team aims to create compelling content that is tailored to your site’s audience and enhances your overall content strategy.
A quick note: this initial email is only for starting our dialogue. All more detailed communications, including agreements and transactions, will be carried out through our official Next Publisher email.
We admire the quality of your platform and are excited to explore how we can work together for mutual benefit.
Looking forward to your prompt reply.
Warm wishes,
Krystal XXXXXXX
Hello Krystal.
Since you neglected to include a link
(in an email sent as HTML no less!)
it's hard for me judge the value Next Publisher will provide for my site,
so I'm going to have to adjust my prices accordingly.
My fee for both guest posts and link insertions is $10,000 (US) per.
So if a guest post also includes a link insertion,
that would be a total of $20,000 (US).
If I'm going to be whoring selling out what Google Page Rank I have,
it's going to cost.
I look forward to hearing back from you.
Sean.
Monday, February 05, 2024
The difficulties in supporting “write-only memory” in assembly
When I last wrote about this, I had one outstanding problem with static analysis of read-only/write-only memory, and that was with hardware that could be input or output only. It was only after I wrote that that I realized the solution—it's the same as a hardware register having different semantics on read vs. write—just define two labels with the semantics I want. So for the MC6821, I could have:
org $FF00 PIA0.A rmb/r 1 ; read only org $FF00 PIA0.Adir rmb/w 1 ; write only, to set the direction of each IO pin PIA0.Acontrol rmb 1 ; control for port A
So that was a non-issue. It was then I started looking over some existing code I had to see how it might look. I didn't want to just jump into an implementation without some forethought, and I quickly found some issues with the idea by looking at my maze generation program. The code in question initializes the required video mode (in this case 64×64 with four colors). Step one involves writing a particular value to the MC6821:
lda #G1C.PIA ; 64x64x4 sta PIA1.B
So far so good. I can mark PIA1.B as write-only
(technically, it also has some input pins so I really can't,
but in theory I could).
Now, the next bit requires some explaining. There's another 3-bit value that needs to be configured on the MC6883, but it's not as simple as writing the 3-bit value to a hardware register—each bit requires writing to a different address, and worse—it's a different address if the bit is 0 or 1. So that's six different addresses required. It's not horrible though—the addresses are sequential:
| bit | 0/1 | address |
|---|---|---|
V0 | 0 | $FFC0 |
V0 | 1 | $FFC1 |
V1 | 0 | $FFC2 |
V1 | 1 | $FFC3 |
V2 | 0 | $FFC4 |
V2 | 1 | $FFC5 |
Yeah,
to a software programmer,
hardware can be weird.
To set bit 0 to 0,
you do a write
(and it does not matter what the value is)
to address $FFC0.
If bit 0 is 1,
then it's a write to $FFC1.
So with that in mind,
I have:
sta SAM.V0 + (G1C.V & 1<<0 <> 0) sta SAM.V1 + (G1C.V & 1<<1 <> 0) sta SAM.V2 + (G1C.V & 1<<2 <> 0)
OOh. Yeah.
I wrote it this way so I wouldn't have to look up the appropriate value and write the more opaque (to me):
sta $FFC1 sta SFFC2 sta $FFC4
The expression (G1C.V & 1<<n <> 0) checks bit n to see if it's set or not,
and returns 0 (for not set) or 1 (for set).
This is then added to the base address for bit n,
and it all works out fine. I can change the code for,
say, the 128×192 four color mode by using a different constant:
lda #G6C.PIA sta PIA1.B sta SAM.V0 + (G6C.V & 1<<0 <> 0) sta SAM.V1 + (G6C.V & 1<<1 <> 0) sta SAM.V2 + (G6C.V & 1<<2 <> 0)
But I digress.
This is a bit harder to support. The address being written is part of an expression, and only the label (defining the address) would have the read/write attribute associated with it. At least, that was my intent. I suppose I could track the read/write attribute by address, which would solve this particular segment of code.
And the final bit of code to set the address of the video screen (or frame buffer):
ldx #SAM.F6 ; point to frame buffer address bits lda ECB.grpram ; get MSB of frame buffer mapframebuf clrb lsla rolb sta b,x ; next bit of address leax -2,x cmpx #SAM.F0 bhs mapframebuf
Like the VDG Address Mode bits,
the bits for the VDG Address Offset have unique addresses,
and because the VDG Address Offset has seven bits,
the address is aligned to a 512 byte boundary.
Here,
the code loads the X register with the address of the upper end of the VDG Address Offset,
and the seven top most bits of the video address is sent,
one at a time,
to the B register,
which is used as an offset to the X register to set the appropriate address for the appropriate bit.
So now I would have to track the read/write attributes via the index registers as well.
That is not so easy.
I mean, here, it could work, as the code is all in one place, but what if instead it was:
ldx #SAM.F6 lda ECB.grpram jsr mapframebuf
Or an even worse example:
costmessage fcc/r "A constant message" ; read only text buffer rmb 18 ldx #constmessage ldy #buffer lda #18 jsr memcpy
The subroutine memcpy might not even be in the same source unit,
so how would the read/write attribute even be checked?
This is for static analysis,
not runtime.
I have one variation on the maze generation program that generates multiple mazes at the same time, on the same screen (it's fun to watch) and as such, I have the data required for each “maze generator” stored in a structure:
explorec equ 0 ; read-only backtrackc equ 1 ; read-only xmin equ 2 ; read-only ymin equ 3 ; read-only xstart equ 4 ; read-only ystart equ 5 ; read-only xmax equ 6 ; read-only ymax equ 7 ; read-only xpos equ 8 ; read-write ypos equ 9 ; read-write color equ 10 ; read-write func equ 11 ; read-write
This is from the source code, but I've commented each “field” as being “read-only” or “read-write.” That's another aspect of this that I didn't consider:
lda explorec,x ; this is okay sta explorec,x ; this is NOT okay
Not only would I have to track read/write attributes for addresses, but for field accesses to a structure as well. I'm not saying this is impossible, it's just going to take way more thought than I thought. I don't think I'll have this feature done any time soon …
Friday, February 02, 2024
It should be obvious by now what day it is, but just in case
I want to ensure everybody that yes, I intentionally made the previous three posts. And while they are similar, they are not in fact, identical. You know, much like Ground Hog Day.
Making it to the Orange Site
A previous post made it to Lobster only to later show up at the Orange Site. How about that?
Making it to the Orange Site
A previous post made it to Lobster only to later show up at the Orange Site. How about that?
Making it to the Orange Site
A previous post made it to Lobster only to later show up at the Orange Site. How about that?
Wednesday, January 31, 2024
How much for the book? I don't think I paid that much for the computer
Now, about that Amiga Hardware Reference Manual link in my previous post—$577.99‽
Seriously‽
I know it's now a niche market, but are there really people buying that book for almost $600?
Good Lord!
I know languages that have support for “read-only memory,” but what about “write-only memory?”
I'm still hacking away on my overengineered 6809 assembler and one feature I've beem mulling over is a form of static access checking. I have byte-level access control when running tests but I'm thinking that adding some form of “assemble time checking” would also be good. I've been writing code hitting the hardware of the Color Computer, and there are semantics around hardware that I don't think many languages (or even assembler) support—write only memory! As the Amiga Hardware Reference Manual states (only referenced here because it's a good example of what I'm talking about):
Registers are either read-only or write-only. Reading a write-only register will trash the register. Writing a read-only register will cause unexpected results.
…
When strobing any register which responds to either a read or a write, (for example copjmp2) be sure to use a
MOVE.W, notCLR.W. TheCLRinstruction causes a read and a clear (two access) on a 68000, but only a single access on 68020 processors. This will give different results on different processors.
The Color Computer isn't quite as finicky
(although the 6809 inside it also does the “read, then write” thing with the CLR instruction),
but there is still memory-mapped IO that is read-only, some that is write-only,
and some that has different meanings when reading and writing.
And while C has some semantic support with volatile
(to ensure reads and writes happen when stated)
and const
(to ensure the read-only nature)
it still lacks a “write-only” concept.
And I've never used an assembler that had “write-only” semantics either.
I'm thinking something along these lines:
org $FF40 DSK.CTRL rmb/w 1 ; write only org $FF48 DSK.CMD rmb/w 1 ; write only org $FF48 DSK.STATUS rmb/r 1 ; read only DSK.TRACK rmb 1 ; these can be read and written DSK.SECTOR rmb 1 DSK.DATA rmb 1
Here, the RMB directive just reserves a number of bytes, with a default access of “read-write.”
The /W or /R designates that label as being either “write-only” or “read-only.”
And if you look closely,
you'll see that both DSK.CMD and DSK.STATUS are defined as the same address.
It's just that writing to that address will send a command to the drive controller,
while reading from that address give the current status.
The only issue I have are hardware registers that can be programmed for input or output.
The MC6821 used in the Color Computer has such registers,
and the issue I have is how to signify this change in state in a program—that at this point in the program,
such-n-such address is “read-write” but afterwards, it's “write-only.”
Discussions about this entry
Dear LinkedIn, I don't think I'm the expert you want answering these questions
I cross post links to my blog on LinkedIn mainly to be contrarian, or at least think I'm providing something different than all the business related stuff posted there. But lately, I've seen notifications there like, “You're one of the few experts invited to add this collaborative article: …” and it's some article about AI, or Agile or the latest one, “Your team is falling behind on project deadlines. What web-based tools can help you catch up?”
Oh … nothing good can come from me answering these questions.
The Repair Culture, Part II—Electric DeoxIToo
I've repaired my Logitech Trackman Marble a few times over the years, but this time the traditional fix didn't work. But I have seen enough Adrian Black computer repair videos to know that perhaps, a liberal application of DeoxIT Spray Contact Cleaner on the buttons might work. I ordered some last week, and when I went out to check the mail, I found it sitting on top of the mail box! I'm surprised it didn't fall off.
Anyway, a liberal amount of DeoxIT in the buttons and yup, that did the trick this time.
Sweet.
![[The future's so bright, I gotta wear shades]](https://www.conman.org/people/spc/about/2023/1023.t.jpg "The future's so bright, I gotta wear shades")