@bread80@mstdn.social avatar

bread80

@bread80@mstdn.social

Amstrad CPC, RC2014, Z80, Raspberry Pi Pico, TTL processors and the occasional bit of Eurorack

This profile is from a federated server and may be incomplete. Browse more on the original instance.

bread80, to random
@bread80@mstdn.social avatar

Now to get memory writes working in the Datapoint simulator. There's a /MEMORY_WRITE_READY input which needs to be driven. The circuit for this is on the keyboard decoder PCB.

Unconnected to the rest of that board, except for a POR output. Not the first bit of circuit I've found spilled onto a different board.

The circuit drives the /MEM_WRITE_READY line while the hardware bootloader reads data from tape. I can just glue it high for now.

A close up of the power on reset and reboot circuit which drives the /MEMORY_WRITE_READY pin and others associated with bootloading.

bread80,
@bread80@mstdn.social avatar

For anyone who may not be aware, the Datapoint has no ROM (except character ROMs). At (re)boot times the machine rewinds the first tape deck and loads the first program record on it. This is done by directly driving the address counters in the processor.

And all of this is done in hardware.

bread80, to random
@bread80@mstdn.social avatar

'Clear the carry tiggle'.

I think they meant to say 'toggle', although twice suggests it may be intentional.

The documentation usually refers to 'flip-flops' as opposed to 'flags', or 'toggles'.

Section 2.6 of the Datapoint Programmers Manual describing the 'Control Flip-Flops'. There are four: carry, zero, sign and parity. Each is reference by a capital letter (C, Z, S or P) with and a subscripted lower case f.

bread80, to random
@bread80@mstdn.social avatar

I like how the assembler has pseudo instructions to load a 16-bit value into the H, L and D, E registers. Strangely there's no equivalent for B, C.

bread80,
@bread80@mstdn.social avatar

The 8008 assembler on the other hand requires some gymnastics to deal with a 16-bit label. The \HB\ prefix is specifying the high byte of the address. Note also, at lest in this codebase, there are no labels for data storage areas. The high byte value uses the label for 256-byte page number number. The low byte uses a magic constant.

I don't know if that's an assembler shortcoming or just coding style (saving code and memory?)

bread80, to random
@bread80@mstdn.social avatar

There's a version of BASIC available for the Intel 8008 called SCELBAL. I've been looing to see it it could be back-ported to the Datapoint 2200.

The first image is the subroutine to increment a 16-bit value in the H and L registers on the 8008. The second is the equivalent for the 2200. One of the additions to the 8008 was INC and DEC instructions (INx, DCx).

On the Datapoint all ALU ops have to go via the A register.

INCHL* LAL AD 1 LLA LAM AC 0 LMA RET

bread80,
@bread80@mstdn.social avatar

...Which means every instance of INx or DCx needs to be modified to involve the A register, and the nearby codes needs to be inspected to see if there is a meaningful value in A. If so that value needs to be moved elsewhere, or the code rewritten to use different registers.

Which, sadly, means the entire code base would need an rewrite :(

bread80,
@bread80@mstdn.social avatar

The Datapoint assembler can even handle expressions! But only three operations: Add, Subtract and 'high-byte'.

bread80, to random
@bread80@mstdn.social avatar

I'm spending the afternoon running through the instruction set in the simulator to test everything.

So far, loads working, as are all the ALU operations, including the two shifts.

I've done my first ever use of the stack (with CALL and RETurn) which checks out okay.

Pretty much the only thing left to test is writes to memory. I'm fairly sure there's still a bug in the simulator code due to time when I'm clocking the memory bits. Should be a simple fix.

bread80, to random
@bread80@mstdn.social avatar

AI in science fiction: Insufficent data, unable to compute.

AI in the real world: Here’s a couple of pages that sound plausible.

bread80, to random
@bread80@mstdn.social avatar

After an evening wrestling with Inkscape I’m ready for an early night. But the diagram actually looks pretty good, and means I’m significantly closer to publishing an article I wrote six months ago.

bread80, to random
@bread80@mstdn.social avatar

I’m secretly happy about the Sonos app-pocalyse. It’s given me the kick I needed to finally ditch it and move to something (hopefully) better.

bread80,
@bread80@mstdn.social avatar

I’m moving to Denon HEOS. I’m hoping that something from an established audio company with a long history - rather than a tech industry start up - will mean a slower path to enshittification.

bread80,
@bread80@mstdn.social avatar

@RetroFunPL New ‘improved’ app, rewritten from the ground up.

The UX is horrible. The key pain point for me is that there doesn’t seem to be any way to connect to the NAS. Although it did work for the first five minutes, but the artists list had no A-Z quick links and I was having to scroll down through several hundred entries.

bread80,
@bread80@mstdn.social avatar

@RetroFunPL zone day I’ll have cable everywhere and LAN sockets. Not sure I want the hassle and disruption just yet though.

Dtl, to random
@Dtl@mastodon.social avatar

Looking at the has anyone wired up the GPIO and done bit banged video from that rather than use the built in video stuff?

bread80,
@bread80@mstdn.social avatar

@Dtl Compared to a Pico it’s only single core and a much slower clock speed. I’m guessing it’s doable but with low resolution and frame rate.

GrantMeStrength, to random
@GrantMeStrength@hachyderm.io avatar

This new sound card for the features a socket to house the fake AY chips that proliferate on Amazon and eBay.

image/jpeg
image/jpeg

bread80,
@bread80@mstdn.social avatar

@GrantMeStrength One day every DIP chip will have a tiny FPGA hidden underneath it.

bread80, to random
@bread80@mstdn.social avatar

I've renamed the EXTERN directive to CALL. That feels a lot more logical given it's function (to call assembly code such as ROM routines).

It also makes it straightforward to implement an RST directive to call assembly via a Z80 RST instruction.

(In the screenshot I've cleaned up the comments in the output to make it easier to read.)

#Quiche #compiler #Z80 #Delphi

bread80, to random
@bread80@mstdn.social avatar

#Compiler update: Write and writeln marks the end of the the refactoring of operations and primitives which has taken up the last few months.

I've also refactored a few other parts to better future proof them.

There a still a few rough edges to smooth off in the expression parser (implicit types) and code generator (parameter loading and validation).

But this means I can now return to interesting stuff :) as well as moving towards some kind of initial (pre-beta) release.

#Quiche #Z80

Output if the test program running on an Amstrad CPC emulator.

partnumber2, to random
@partnumber2@c.im avatar

60 years ago today this happened. Up until then we only had 2 (TWO) channels. You nippers don’t know how good you’ve got it with your on-demand streaming services. 😎

video/mp4

bread80,
@bread80@mstdn.social avatar

@partnumber2 That content is so close to a deadpan comedy sketch that I’m having to remind myself it’s real.

bread80, to random
@bread80@mstdn.social avatar

I/O on the 2200 (as I'm understanding it) :

The instructions are similar to the i8008. Bits 4 to 1 of the bytecode code the I/O port. 32 addresses, but the first 8 are inputs, mapped to instructions IN 0..7. The remaining 24 are outputs mapped to instructions OUT 0..23.

The Datapoint uses the instruction EX for outputs (short for external IIRC)). Rather than port numbers it uses names. The first 8 are generic:
EX ADR
EX STATUS
EX DATA
EX WRITE
EX COM1 though EX COM4
🧵

bread80,
@bread80@mstdn.social avatar

EX ADR selects a device.

For output:
EX WRITE writes data to the selected device.
EX COMn send device specific COMmands (they are not serial ports).

EX STATUS and EX DATA are use for /input/. They tell the device to prepare to send status info or data.

There's a single INPUT instruction which reads the status or data from the device selected by EX ADR.

bread80,
@bread80@mstdn.social avatar

To poll a device for input data:
Set A to device address
EX ADR ;Device selected
EX STATUS ;Prepare to read status byte
INPUT ;Read status byte
Check value. If data available:
EX DATA ;Prepare to read data
INPUT ;Read data
Data is now in A register.

All of which is horribly long winded.

bread80,
@bread80@mstdn.social avatar

However, the output port is decoded on the decoder board using bits 4..1 of the instruction register. They're exposed on pins on the processor boards edge connector.

The instruction decoding for the INPUT command looks to be partial enough that it is issued irrespective of the port address. If so another board could be decoding I4..I1 to give an input port address.

(But the pinouts for every board are unique to that board. It's possible no other board has access to them).

bread80, to random
@bread80@mstdn.social avatar

And I only just found this. I didn’t realise the Flan name actually made it into production.

This means it’s a revision 4 board, from the first production run. The run with bugs in the video chip and ROM.

bread80,
@bread80@mstdn.social avatar

@saustrup Just something I read on the Enterprise Forever forum. The issue 4 had the Flan name on the board. Those were the boards used in the Enterprise 64s. I don’t know anything beyond that. I got the impression that was the first production run. Presumably the earlier issues were prototypes.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • JUstTest
  • thenastyranch
  • magazineikmin
  • mdbf
  • GTA5RPClips
  • everett
  • rosin
  • Youngstown
  • tacticalgear
  • slotface
  • ngwrru68w68
  • kavyap
  • DreamBathrooms
  • khanakhh
  • megavids
  • tester
  • ethstaker
  • cubers
  • osvaldo12
  • cisconetworking
  • Durango
  • InstantRegret
  • normalnudes
  • Leos
  • modclub
  • anitta
  • provamag3
  • lostlight
  • All magazines
    •