code logs -> 2023 -> Thu, 02 Feb 2023< code.20230201.log - code.20230203.log >
--- Log opened Thu Feb 02 00:00:25 2023
01:06 Degi [Degi@Nightstar-frgq4p.pool.telefonica.de] has quit [Ping timeout: 121 seconds]
01:08 Degi [Degi@Nightstar-m4k.djm.14.89.IP] has joined #code
01:51 gizmore|2 [kvirc@Nightstar-6mvp6d.dip0.t-ipconnect.de] has joined #code
01:52 gizmore [kvirc@Nightstar-ilo0if.dip0.t-ipconnect.de] has quit [Ping timeout: 121 seconds]
02:55 Pink [Pink@Nightstar-dgaf27.ph.cox.net] has joined #code
08:10 Vorntastic [uid293981@Nightstar-phvupn.irccloud.com] has joined #code
08:10 mode/#code [+qo Vorntastic Vorntastic] by ChanServ
09:42 abudhabi__ [abudhabi@Nightstar-q7v4ii.adsl.tpnet.pl] has joined #code
09:45 abudhabi_ [abudhabi@Nightstar-4ei6ge.adsl.tpnet.pl] has quit [Ping timeout: 121 seconds]
12:39 Vorntastic [uid293981@Nightstar-phvupn.irccloud.com] has quit [[NS] Quit: Connection closed for inactivity]
14:50
<&ToxicFrog>
McMartin: so, apropos our conversation yesterday, symbol and I have now both finished the software chapters of NANDgame and are disappointed that it has you build a whole-ass stack machine and then doesn't ask you to do anything with it.
14:50
<&ToxicFrog>
and symbol is thinking they might potentially enjoy poking at a real-world system that is an incremental increase in complexity vs. the nandgame chip.
14:50
<&ToxicFrog>
And since you do a lot of retrocoding, I thought you might be a good person to ask for recommendations!
14:50
<&ToxicFrog>
For reference, the nandgame processor is 16 bits, 2 registers with some restrictions on what you can do with them, a fairly minimal instruction set, a 512x256 monochrome bitmap display memory mapped at $4000 and a few bits of input mapped at, IIRC, $7ffe.
14:50
<&ToxicFrog>
My first thought was "gameboy" because on the surface that looks only slightly more complicated (160x144 2bpp display, 8 bits of input) but it looks like the internals are a lot more complicated, with the Z80-inspired core having a lot of complications and the display only having tilemap/spritemap modes -- it looks like you don't get pixmap modes until the GBA.
14:51
<&ToxicFrog>
So based on that I was wondering if something 6502-based would be better, but there are a lot of 6502-based platforms and I know nothing about most of them.
15:03 Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code
15:03 mode/#code [+qo Vornicus Vornicus] by ChanServ
16:34 Kizor [a@Nightstar-nfsqa7.yok.fi] has quit [Ping timeout: 121 seconds]
17:00 macdjord [macdjord@Nightstar-04p1sk.dsl.bell.ca] has quit [[NS] Quit: Deep inside, every housecat believes themself to be just a temporarily embarrassed tiger.]
17:03 Emmy [Emmy@Nightstar-qo29c7.fixed.kpn.net] has joined #code
17:07 macdjord [macdjord@Nightstar-04p1sk.dsl.bell.ca] has joined #code
17:08 mode/#code [+o macdjord] by ChanServ
19:20 Kizor [a@Nightstar-nfsqa7.yok.fi] has joined #code
19:28 Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Connection closed]
20:37
<&McMartin>
ToxicFrog: I have received this message but need to turn it over in my head a bit before I give it the response it deserves.
20:46
<&ToxicFrog>
McMartin: no rush.
20:47
<&ToxicFrog>
I went rummaging around for a while and concluded that the 6502 is probably the optimal choice for "incremental increase in complexity over the nandgame core + widely used enough to be available as a platform", with the Commodore 64 or PET probably being good platform choices
20:48
<&McMartin>
I am likely to end up suggesting the C64, but the *reasons* for this need some detail I need to think through to make sure that the Atari 800 isn't the right answer.
20:48
<&ToxicFrog>
They have also expressed interest in the Arduboy platform, which is an atmega32u4 connected to six bits of input and a small monochrome screen, and while the AVR is more complicated than the 6502 I think it's less weird than the Z80.
20:48
<&McMartin>
But the hot take is "C64 has All The Things, but none of them are convenient *except* for its equivalent of stdio, which is absolutely unparalleled amongst the 8-bits"
20:49
<&McMartin>
"Z80 is too much" and "needs a bitmap mode" pretty much crashes you down to Apple II, Atari 800, and C64
20:49
<&McMartin>
And Apple II is not ergonomic at all because it's effectively a full generation behind the other two
20:50
<&ToxicFrog>
In rummaging, I stumbled across https://www.assemblytutorial.com/6502/ which appears to be a "learn 6502 asm on like all the platforms at once" tutorial sequence, which symbol thought sounded very interesting indeed, but neither of us have taken enough of a look to tell if the tutorials are actually any good
20:50
<&McMartin>
I can maybe scan through that this evening
20:50
<&McMartin>
For "what does it take to *get a file to run with my stuff*" I have my own collection of "platform guides"
20:50
<&ToxicFrog>
As noted, no rush, they probably won't have enough bandwidth to actually start poking things until sometime next week at the earliest
20:51
<&McMartin>
But they're often targeting a level that I think is somewhat to the side of where they are, both above (more familiarity with BASIC and the machine in question's principles of opreation) and below (no real knowledge of how to do anything with assembly language)
20:51
<&ToxicFrog>
And yeah, I came to the same conclusion re: 6502 + bitmap mode and what that restricts you to
20:51
<&McMartin>
The Atari 800's bitmap mode is extremely configurable and is the only one I'm aware of that lets you just lay out pixels in neat rows.
20:52
<&ToxicFrog>
The PET made the list because while it does not support raster graphics at all, "put text on the screen" is relatively straightforward and you can do ascii art and whatnot with it.
20:52
<&McMartin>
Yep, but there's nothing the PET can do there that the C64 can't, and "the" PET is a misnomer because there were a billion subtly incompatible models.
20:52
<&ToxicFrog>
Aah, I wasn't sure if the C64's text mode was...weirder
20:53
<&McMartin>
C64 has the same charsets, but mem-mapped screen IO is just "array at $0400 with screen codes" and "array at $d800 for color codes" and that's it
20:53
<&McMartin>
The screen codes aren't the PETSCII codes, and PETSCII is weird too, but these traits are shared with the PET (and the C128 that came after it, and the VIC-20 that came between them)
20:53
<&ToxicFrog>
A lot of what I've gathered from your blog posts about C64 programming is that it can do a lot, but a lot of what you can do requires contortions that feel very weird coming at it from other platforms
20:54
<&McMartin>
Most of my articles are specifically about bending the system to do things it was not strictly speaking intended to do, or that were intended in the sense of "we won't forbid these kinds of tricks"
20:54 * ToxicFrog nodnod
20:54
<&ToxicFrog>
Ok, time to go climbing, but I will be back later
20:55
<&McMartin>
If you stay within the spec sheets, and you're working in pure asm, a lot of C64 work turns out to just be "ask the computer to do a thing and then it does it", with the remaining ugly bits boiling down to "how much does the !BIOS do for me" and "aren't linkers supposed to exist to handle bullshit like this"
20:55
<&McMartin>
And I can get them past the latter very quickly if they get stuck at all ;)
20:56
<&McMartin>
(Embedding a pure-machine-code program so that it loads with the standard BASIC LOAD/RUN commands -- C64 doesn't have an independent DOS shell -- is basically a matter of starting your code at a specific address and then putting a specific fixed sequence of a dozen or so bytes in front of it. As long as all your code and data then stays within 16KB, you also never have to worry about the intricacies of its
20:56
<&McMartin>
internal memory mappers.)
20:58
<&McMartin>
The Atari 800 has more colors, chunkier and more sensible displays, but the hardware is flexible enough that doing simple things is much more involved; instead of JSR $FFD2 to take the PETSCII code in the accumulator and dump it to stdout, you have to construct an I/O Request block and submit it to the BIOS
20:59
<&McMartin>
It is much, much more like a call to write(2), and the general nature of the calls left me unsurprised to learn that the folks who worked on the Atari home computers went on to Microsoft to help invent USB
20:59
<&McMartin>
(and getting a bitmap to work to your specifications requires programming the ANTIC coprocessor, which, while this is not *difficult*, is an extra initial hurdle and we want to minimize those)
21:00
<&McMartin>
Your link is blocked by Malwarebytes, for the record
21:01
<&McMartin>
https://skilldrick.github.io/easy6502/ has also crossed my desk and it includes a tiny fantasy system in JS
21:06
<&McMartin>
The standard manuals for C64 development are the C64 Programmer's Reference Guide and "Compute's Mapping the C64" by Sheldon Leemon; both are available for download in a variety of electronic formats including .txt
21:07
<&McMartin>
The latter is a comprehensive memory map and is not your *first* stop; the former spends half its time teaching BASIC but the other half being an extremely thorough tutorial in actually getting graphics and sound to work
21:07
<&McMartin>
As well as full documentation for all the BIOS calls, but the ones that matter going in are CHROUT and GETIN, which print a character and scan the keyboard for a potential keyboard press, respectively.
21:08
<&McMartin>
Basically everything but those two is going to involve memory-mapped I/O
21:29
<&McMartin>
And, of course, if you want to write anything of any size, I specifically wrote the Ophis toolchain to get out of your way as much as possible.
21:29
<&McMartin>
I haven't done a binary release of it in a decade, but https://github.com/michaelcmartin/Ophis is a fairly self-contained pack of Python 3 scripts nowadays.
23:27 Emmy [Emmy@Nightstar-qo29c7.fixed.kpn.net] has quit [Ping timeout: 121 seconds]
23:46
<&ToxicFrog>
McMartin: ooo, thanks for the link to easy6502, that looks relevant
23:49
<&ToxicFrog>
McMartin: as for why assemblytutorial is blocked by your antivirus, it may be because it has an img tag pointing to file://N:/webcontent/...
23:50
<&ToxicFrog>
The page itself is 90s as hell and doesn't even have any js
--- Log closed Fri Feb 03 00:00:26 2023
code logs -> 2023 -> Thu, 02 Feb 2023< code.20230201.log - code.20230203.log >

[ Latest log file ]