Retrocomputing during lockdown

Now, I have not set up a gopher server. But I’m pretty sure I could pound out a simple one in, well, probably anything that can accept a socket in a 1/2hr.

It’s, by design, very simple. But at the same time, it can have hidden complexity.

A simple example is that the structure that is returned: the item type, description, path, host, port is the meat of it. These could be trivially (albeit, tediously) maintained by hand as text files. If all you were publishing were filenames and directories, then a server is basically trivial with some simple rules. Such as anything that’s an actual directory is, well, a directory. Anything ending in .txt is a type 0 text file, and anything else is a type 9 binary file.

And…that’s it! A simple shell script connected to inetd could do the trick.

Now, getting beyond that, where you have more descriptive titles than “notes.txt”, well, that’s where things get more complicated. How do you manifest that meta data, etc. Hardly insurmountable.

If you want to maintain the directories by hand, you can adopt a simple thing like .gopher_index contains the gopher formatted information.

1 Like

A quick Commodore BASIC implementation of “Conway’s Game of Life”, in memoriam John H. Conway:

1 Like

There was an online meetup yesterday, most of the day, on a single video call with maybe 15 people: it was the second virtual ABUG, for Acorn and BBC Micro users. Lots of interesting chat and some show and tell of works in progress. It looked a bit like this, but higher resolution:
image
(ABUGs usually take place over a long weekend, at a hotel or museum, so an all-day call was in some ways an abbreviated version.)

3 Likes

Small upade on Life for the PET 2001 (see above): I optimized the loop for the screen update (featuring POKEs to the video RAM) with considerable results. What did I do? Just reuse a variable. As it was, the address used for the base address of the POKE was the last one defined, the one I reused was the third one defined (with about 8 variables defined in between). The speed-up is considerable in relation to how small that optimization is.

Meaning, we all know, how important it is to define frequently used variables first, since BASIC does a sequential search on variable names, but there’s still a difference in knowing this and seeing it in action, even in a relatively small loop. Also, doing the same with less variables is definitely worth it. (And this is also, where true spaghetti code begins… :wink: )

Hurrah - any chance you could make the playfield a torus? I think the edge effects at present prevent the spontaneous discovery of gliders and similar.

You mean, copying arrays on each frame or handling edge cases on the edges (now we finally know, why they are called like this)? I mean, this is BASIC! :slight_smile:
But I actually like how cells build up at what become borders in this implementation. And, provided you chose the right dimensions, it’s much like blinkenlights on a really slow computer. (This may have been even better before the update, when there was still more of a noticeable sweep to the screen update.)

I’m naively supposing that a MOD operation here and there would allow the edges to wrap in a natural way. If the board size is a power of two, that’s an AND operation. But, possibly, neither is available!

A mod operation in Commodore BASIC? Those spoiled BBC Micro kids…

(AND, however, is available. But the true concern regarding the main loop is rather, if using a subscripted integer variable for the play field is actually worth it. This means, spending the time for parsing the “%” on each of the 8 lookups versus saving 3 bytes of RAM on each cell. As a sidenote, integer variables aren’t any faster in Commodore BASIC, they are actually the same, but slower for the extra character in the variable name. The difference is only in subscripted variables/arrays and the space reserved for each individual subscript.)

1 Like

I’ve got to admit I rather like the low-res, blocky look. It looks appropriate for a retrocomputing videochat.

2 Likes

A post was merged into an existing topic: (Conway’s) Life in BASIC

And one of the better ones out there, actually. To this day I’m still reasonably comfortable working in ed (it was my first editor on Unix, actually), and I’m continually surprised by how bad pretty much every microcomputer editor is in comparison.

My workbench isn’t too exciting today, since after building a PSU for my C64 last week I’ve moved back to working more on software stuff. (Although I don’t know if several days getting deep into the gory details of the Apple II floppy disk system really counts as “software.”)

There is, however, that cute little National (Panasonic) JR-100 that arrived the other day that’s waiting for me to give it a go at powering it up. It’s a 6802-based machine, which is refreshing. Unfortunately it wants a DIN-4 plug for power, of which I have none, so while I’m waiting for the ones I’ve ordered to show up I’ll probably have to open up the thing and see if I can get power into it some other way. (If you want to see what it looks like, there’s a video on YouTube of a cute demo running in an emulator.)

Today I finally implemented the code in 8bitdev for building disk images and loading them up in an emulator, so I now can edit a file and with a couple of keystrokes have the system assembled, unit tests run, a disk image built and LinApple pop up and immediately run the program, which is pretty nice. The next step there is to do the same with VICE so I can do PET/VIC-20/C64 programs as well.

2 Likes

Radio Shack, came out similar computer as the JR-100,
just after the COCO III came out. I think it was like $59.
vs $150 for the COCO III. 64K,BASIC and tape I/O.

You’re probably thinking of the TRS-80 MC-10, released in 1983, two years after the JR-100 and three years before the CoCo III (but three years after the original CoCo). It used a Motorola MC6803 processor, not an MC6802; the 6803 had some extra instructions and other features.

The MC-10 had less RAM and expandability than even the JR-100, though it did have a colour display like the JR-200.

Had a bit of a retrotechnical investigation today with @hoglet: he’s been bringing HDMI video output into play from the PiTubeDirect project. When it’s ready, the Pi in your Beeb which can act as a high performance retro-authentic second processor will also be able to act as a high definition and high performance text and graphics output device, obeying the usual MOVE DRAW and PLOT commands for lines, triangles and circles. Another win for the architectural foundations of the BBC Micro, where the VDU subsystem is separable (mostly) and resolution-independent. There’s a bit of a gotcha at present for line-editing, and a bit of a puzzle about hiding the latency of expensive operations like scrolling. But puzzles can be solved!

1 Like

The color scheme of that JR-100 reminds me of the Mattel Aquarius - which is universally regarded as an awful failure.

Someone blogged about using a IIc+ as a VT220 emulator - see this thread:
Working from home on the //c+

1 Like

A post was merged into an existing topic: Working from home on the //c+

Had another hack session this afternoon, having made a bit of progress over the weekend with @Revaldinho, helping him patch his C model of Ferranti’s 16 bit micro into PiTubeDirect, and today we managed to get the first sign of life from the new second processor:

(That’s a BBC Master, a Pi with a level shifter hanging off the Tube port, and my trusty monochrome monitor showing the boot message produced by the F100 code. All the F100 code is written in assembly, so far. The Master’s BASIC ROM is announcing itself, but it’s a 6502 Basic and doesn’t play a part here.)

There are a few steps yet, to support a few more OS calls, so we can support a command line and do file access. We’ll probably add a debugger too - that’s written in C, runs on the Pi, and talks over a serial port to offer a command line interface, with visibility and control for things like breakpoints and single stepping. @hoglet has offered advice and assistance…

4 Likes

A bit more progress yesterday! Thanks to @hoglet I got a serial debug connection to the Pi and we could run the debugger which he’d recently ported to this new core. We could then use breakpoints, watchpoints, disassembly, single-stepping:

Raspberry Pi Direct 0 65C02 (fast) Client
emulator speed 0
Copro Memory size 0
             cycle counter = 1527923648
              I_CACHE_MISS = 925197
              D_CACHE_MISS = 177
tube reset - copro 0
New Copro = 28
             cycle counter = 222881468736
              I_CACHE_MISS = 236122456
              D_CACHE_MISS = 16728
tube reset - copro 28
Raspberry Pi Direct 28 Ferranti F100-L Client
emulator speed 0
Copro Memory size 0
             cycle counter = 226694210944
              I_CACHE_MISS = 236122755
              D_CACHE_MISS = 151002
tube reset - copro 28
>> b 800
Exec breakpoint set at 0800
cpu: F100 debug enable = 1
>>              cycle counter = 6936630720
              I_CACHE_MISS = 97360480
              D_CACHE_MISS = 799
tube reset - copro 28
Exec breakpoint hit at 0800
0800 : 8000 7c01      : LDA  ,7c01
>> r
     ACC = 0000
      OR = 0040
      PC = 0800
     PSR = F:0 M:0 C:0 S:0 V:0 Z:1 I:0 
>> r pc 896
      PC = 0896
>> c
Running
>> 

And what is that mysterious program at 0896? It’s @Revaldinho’s recent addition to the ROM, and we can watch it sending characters up to the Beeb:

>> r pc 896
      PC = 0896
>> d 896
0896 : 8000 0fff      : LDA  ,0fff
0898 : 4003           : STO   0003
0899 : 8000 ff2a      : LDA  ,ff2a
089b : 4002           : STO   0002
089c : 8000 0002      : LDA  ,0002
089e : 4903           : STO  /0003+
089f : 7002 089c      : ICZ   0002 089c
08a1 : 8000 ffc0      : LDA  ,ffc0
08a3 : 400a           : STO   000a
08a4 : 8000 0000      : LDA  ,0000
08a6 : 4005           : STO   0005
08a7 : 400b           : STO   000b
08a8 : 4004           : STO   0004
08a9 : 8000 00d5      : LDA  ,00d5
08ab : 4006           : STO   0006
08ac : 9000 1000      : ADD  ,1000
>> c
Running
Mem Wr watchpoint hit at 083b : 7ef9 = 0033
Mem Wr watchpoint hit at 083b : 7ef9 = 0031
Mem Wr watchpoint hit at 083b : 7ef9 = 0034
Mem Wr watchpoint hit at 083b : 7ef9 = 0031
Mem Wr watchpoint hit at 083b : 7ef9 = 0035
Mem Wr watchpoint hit at 083b : 7ef9 = 0039
Mem Wr watchpoint hit at 083b : 7ef9 = 0032
Mem Wr watchpoint hit at 083b : 7ef9 = 0036
Mem Wr watchpoint hit at 083b : 7ef9 = 0035
Mem Wr watchpoint hit at 083b : 7ef9 = 0033
Mem Wr watchpoint hit at 083b : 7ef9 = 0035
Mem Wr watchpoint hit at 083b : 7ef9 = 0038
Mem Wr watchpoint hit at 083b : 7ef9 = 0039
Mem Wr watchpoint hit at 083b : 7ef9 = 0037
Mem Wr watchpoint hit at 083b : 7ef9 = 0039 

You’ve got to love the unique assembly syntax.

1 Like

Not really retrocomputing, but related: I made a playfield editor for the Atari VCS / Atari 2600 (the 40-fat-pixel background graphics), generating ready-to-use assembler code in realtime.

This and other tools may be found at a common landing page: Atari VCS Tools

3 Likes