Where to start from.

Now that I've set an environment for the development of tests that I can share with you, I am going back to the emulator

My first idea is to design a main section based on a Finite State Machine, that is executed every cycle of the host application. In my Replit project this application is the SDL based environment, while in the STM32 board is a specific H7 targeted project.

I would like to develop this emulator as a scalable and portable application to have it running on different target platforms. My goal here is not to build a commercial product, but to learn, experiment and enjoy the development of an Apple Macintosh 128k.

There are different approaches in building an emulator. Usually, it should be best to start from a minimalist virtual system, so CPU, RAM, ROM, and the minimum hardware used to control the system. But it may not be fun. The systems that I have written a emulator were equipped with a Video Display Processor, so I started to write my emulators from the video stage. This let me to set a visual output system to be used to show debug information.

When I asked ChatGPT to give me information about the Apple Macintosh 128k, it provided me some details on the graphics section. I to was...

Good morning, thanks for this initial information. Now let's proceed in order. I would like a more detailed description of the hardware divided into areas.

And the answer for the graphics section was...

3. Display:

• Tipo: CRT (tubo a raggi catodici) monocromatico incorporato
• Dimensione: 9 pollici (diagonale)
• Risoluzione: 512 x 342 pixel, il che offriva un'immagine sorprendentemente nitida e dettagliata per l'epoca, supportando l'interfaccia grafica dettagliata del Mac.

Actually not many details, Ineed to understand how graphics is generatedfor the video signal.

How graphics are generated on Apple Macintosh 128k?

The graphics on the Apple Macintosh 128K are generated through a combination of hardware and software components. Here's a basic description of the process:

1. Microprocessor: The Macintosh contains a Motorola MC68000 microprocessor, which is the central processing unit responsible for executing instructions, including those for graphic generation.

2. Video Display: The Macintosh uses a bit-mapped video display. This means that the screen is composed of a grid of pixels, where each pixel's state (on or off) is controlled by a corresponding bit in the computer's memory.

3. Video Memory: The video generator uses 21,888 bytes of RAM to create a bit-mapped video image that is 512 pixels wide by 342 pixels tall. Each bit in this memory range controls a single pixel: a 0 bit represents a white pixel, and a 1 bit represents a black pixel.

4. Screen Buffers: There are two main screen buffers in the memory from which the video circuitry reads information to create the screen display: the main buffer and the alternate buffer. The starting addresses of these buffers depend on the total memory available in the Macintosh.

5. Video Scanning Pattern: A full screen display consists of 342 horizontal scan lines. The video scanning pattern includes a vertical blanking interval, which is the time taken by the electron beam to move from the last line of one frame to the first line of the next frame.

6. Toolbox and Operating System Routines: To maintain software compatibility across the Macintosh line and to allow for future changes to the hardware, developers are strongly advised to use the Toolbox and Operating System routines wherever possible for graphics generation.

7. Memory Addresses and Screen Size: It's important to note that memory addresses and screen size may differ across different Macintosh models. Therefore, developers should retrieve the video base address and bit mappings directly from the system to ensure compatibility.

The graphics generation process is designed to be flexible and to provide a high degree of control to the software, allowing for the creation of rich graphical user interfaces and applications that were a hallmark of the early Macintosh computers.

From this it seems that the CPU is responsible for drawing the graphics on the video frame buffer. When a screen has been drawn, somehow the CPU Enables the transfer of data to VIDEO through specific circuits respecting the timings of the video signal. There doesn't appear to be a GPU or VDP.

This could make your job of implementing video output much easier.