Macintosh 128K

[tcdev]

I can't help myself. :o

Stuck in a rut with the Gameboy, the lure of starting a new system was too much. Tonight I started looking at the Mac, specifically the Macintosh 128K.

The usual procedure; seeded some dual-port RAM (in this case 24K) with a memory dump from MESS and hooked up the display (bitmap) controller. I'm greeted with the so-called 'Question Disk'. Monochrome bitmaps are particularly trivial in the PACE framework, so it's not much of an achievement... more time was spent setting up the project and source files...

Next step is to add the 68k CPU, the ROM and some RAM and see what transpires... doesn't look to be particularly difficult, until you start to add floppy disk drives. ;)

[tcdev]

I've added the CPU, the ROM, and 32KB of RAM. I've added the 6522 PIA and the VBLANK and 1Hz interrupts. Added a hack for the cold-start vectors...

According to this (http://www.bigmessowires.com/2011/09/14/sad-mac/) and this (http://www.bigmessowires.com/2011/09/18/question-mark-disk/), that should be enough to at least get the sad face. Alas, nothing thus far. No interrupts generated from the PIA, so I'm guessing the PIA isn't configured properly!?! :confused:

Now the fun part... tracing execution to see where I've stuffed up... :(

[RedskullDC]

Hi TC,
I've added the CPU, the ROM, and 32KB of RAM.

32Kb doesn't sound like it is going to be enough.
Screen mem on it's own is 21888 bytes IIRC.

This page has some good low-level MAC info :
http://www.mac.linux-m68k.org/devel/plushw.php

I'd take a stab and say you need to emulate the PWM circuitry before it will fire up. I do vaguely recall that the early MAC/MAC+ roms check that the PWM stuff is working.

Have got schematics/heavy-duty tech info on the early macs if you need it :)

Cheers,
Leslie

[tcdev]

32Kb doesn't sound like it is going to be enough.
Screen mem on it's own is 21888 bytes IIRC.

I'd take a stab and say you need to emulate the PWM circuitry before it will fire up. I do vaguely recall that the early MAC/MAC+ roms check that the PWM stuff is working.

Got 24KB of screen memory as well as 32KB RAM.

According to the blog entries I linked to, 32KB is enough to see 'sad face' at least, and there was no mention of PWM to get the 'Question Disk' screen. I was surprised that so little was required, but that's what has been reported...

I've temporarily switched to the DE1 just so I have flash (ROM) and 128K (RAM). Had to remove video memory to run SignalTap... WIP. :eek:


Have got schematics/heavy-duty tech info on the early macs if you need it :)
Very early days yet. Will let you know if I need some more info - thanks!

[tcdev]

Not much to report, except that I have ported it to the DE1, so I can use external FLASH for the system ROM (64KB) and SRAM for the system RAM (128KB).

Still not seeing the 'Sad Face'...

[RedskullDC]

Hi TC,
Not much to report, except that I have ported it to the DE1, so I can use external FLASH for the system ROM (64KB) and SRAM for the system RAM (128KB).
Still not seeing the 'Sad Face'...

How far is it getting?

Can you see the processor executing code?

Sure you've thought of this but Little/Big endian issues with saving the ROM to the flash?

Cheers,
Leslie

[RedskullDC]

Still not seeing the 'Sad Face'...

Just saw this code in the Mac128k/platform.vhd:

-- video ram $3FA000-$3FFFFF
-- - $3FA000-$3FBFFF
vram0_cs <= '1' when STD_MATCH(cpu_a, X"3F"&"101------------") else
'0';
-- - $3FC000-$3FFFFF
vram1_cs <= '1' when STD_MATCH(cpu_a, X"3F"&"11-------------") else
'0';

Maybe i'm reading it wrong, but it looks to me like it's hardcoded to expect 4MB ram.
Not going to work if you only have 128K attached :(

Select logic doesn't look correct anyway.

In a 128K MAC main screen starts at $1A700 and alt screen starts at $12700
In a 512K MAC it's $7A700 and $72700

From tech docs:

System Main Screen Alternate
MAC 128K $1A700 $12700
MAC 512K $7A700 $72700
Macintosh Plus, 1Mb $FA700 $F2700
Macintosh Plus, 2Mb $1FA700 $1F2700
Macintosh Plus, 2.5Mb $27A700 $272700
Macintosh Plus, 4Mb $3FA700 $3F2700

-------------

Real MAC video address generator *always* sends $FF for the high 8 bits of the 24-bit video address. However, machines with less than 4MB will ignore the high bits, which is why the screen memory always appears near the top of available memory.

(Later machines with 32bit address bus probably send $FFFF as the top 16bits of the video address, though don't quote me on that...)

Cheers,
Leslie

[tcdev]

To be honest, I've really just taken the information on the PlusToo blog pages as gospel, and hacked something together with as little effort as possible in order to see 'something run'. The only other research I've done on the Mac is look at the MESS driver. :o

The code was executing the ROM correctly, at least before I added the memory overlay logic. And (now) using the Plus ROM (not the 512K), it clears the screen and displays what appears to be the 'Sad Mac' icon, with a nonsensical error code. Below the error code is a cycling bit pattern, which suggests that the memory tests are running?!?

So it would appear that the screen is being updated at some point... although I'm sure your information is correct. I guess I just got lucky somewhere... looking at the PlusToo code, the screen is (also) hard-coded to that address and the comment says "it'll wrap properly" - though that doesn't necessarily mean that my implementation will.

I really need to sit down and do some proper research into the Mac hardware, and perhaps disregard what I've already read... which is as likely that I mis-interpreted as it's wrong.

When I get the chance, I'll debug it 'properly' - trace through the ROM execution and see where it diverts from a known good source (usually MESS). At this stage it could be anything I've done, from address decoding to 8->16-bit flash to write timing to VIA clocking...

It really was a quick 'suck it and see' effort as my spare time atm is next to zero... :(

[RedskullDC]

Hi TC,


The code was executing the ROM correctly, at least before I added the memory overlay logic. And (now) using the Plus ROM (not the 512K), it clears the screen and displays what appears to be the 'Sad Mac' icon, with a nonsensical error code. Below the error code is a cycling bit pattern, which suggests that the memory tests are running?!?

It really was a quick 'suck it and see' effort as my spare time atm is next to zero... :(

Just trying to help where I can, it's all good fun anyway!


I had a better look at the code over lunch.

What I think is happening:

1. ROM routines are running.
2. ROM tries to establish how much memory is in the machine.
3. Tests the Last word of memory on what it thinks are the *expected* memory boundaries.:
128K = $1FFFF
512K = $7FFFF
1MB = $FFFFF ...
4MB = $3FFFFF

4. Finds memory existing at end of 4MB boundary as the VRAM1_cs responds to $3FFFFF
ROM thinks machine has 4MB and sets internal pointers to main screen being at $3FA7000-$3FFC80 ($5580 bytes).
This is why you can see screen being cleared and SAD-FACE displayed.

5. At some point ROM will try to allocate non-existent memory in the 'hole' between end of SRAM memory and $3FA000 where the video ram starts.

6. Crash!! :eek:


Since there is only 512K SRAM on the DE1, why not have it respond from
$0-$79FFF and have the Video ram respond from $7A000-$7FFFF?

This will eliminate the memory hole.

At some point the alternate screen memory area at $72000-$77580 may need to be emulated, though not all programs use it.

Cheers,
Leslie

---------
P.S What you did this morning will cause mirrors of the screen through mem space :(
vram0_cs <= vram_cs when cpu_a(15 downto 13) = "101" else '0';
-- - $3FC000-$3FFFFF
vram1_cs <= vram_cs when cpu_a(15 downto 14) = "11" else '0';

[RedskullDC]

By the way....

http://myoldmac.net/FAQ/SADerror.htm

Has more info on the SAD FACE error codes

Cheers,
Leslie

[tcdev]

P.S What you did this morning will cause mirrors of the screen through mem space :(
vram0_cs <= vram_cs when cpu_a(15 downto 13) = "101" else '0';
-- - $3FC000-$3FFFFF
vram1_cs <= vram_cs when cpu_a(15 downto 14) = "11" else '0';
I don't think so - it qualifies 'vram_cs'!?!

[tcdev]

Since there is only 512K SRAM on the DE1, why not have it respond from
$0-$79FFF and have the Video ram respond from $7A000-$7FFFF?
OK, makes sense... I'm trying this now...

[tcdev]

Just realised I'm clocking the DE1 FLASH too fast... :o

[RedskullDC]

I don't think so - it qualifies 'vram_cs'!?!

Hehe quite right, my bad :rolleyes:

[tcdev]

Hmm... I need to slow down the accesses to the flash. This would normally be quite trivial, but the complication is the fact that the flash on the DE1 is only 8 bits wide... so I need to sit down and work out the best way to do it.

One thing I didn't notice was the fact that the TG68 core uses both edges of the clock. Steve has made use of this fact in his PlusToo implementation; his RomAdapter module also uses both edges of the 8MHz clock...

It's a little more complicated because I tend to avoid gated clock designs, and so I'm using a 32MHz CPU clock with an 8MHz clock-enable on the TG68 core - the clock-enable is only 1/32MHz width. I need to come up with another scheme that allows me to synchronise the byte-wide flash accesses with the fetch cycle of the 68K, and obviously delaying DTACK in the process...

And Chris is reminding me that his 100% finished GameBoy sound module is waiting for something to be hooked up to... :o

[bigmessowires]

I'm happy to answer any questions about my Plus Too design if it's a help. Looks like you're making great progress already!

As for detecting the size of memory and location of screen memory, it's been a few months since I looked at the ROM routines, but as I recall they write a test value to memory locations at increasing powers of two, until it finds the first location where memory address 0 is mirrored. That determines the size of RAM. So it should be fine if your RAM responds to addresses in the 4MB range, as long as it also responds to lower address ranges, where the mirroring will be detected first.

I used a hard-coded address for screen RAM that's correct for a 4MB Mac. If you strip off the higher bits that will be ignored on a Mac with less memory, then it should wrap around to the correct screen RAM address for any memory size. It works for 512K at least, but I never tested any other sizes.

I didn't implement alternate screen memory for my project. I'm pretty sure it's not used by either the ROM routines or Mac system software.

Yeah, the flash memory on the DE1 board is annoyingly slow and only 8-bit wide as well. :-( If you don't like the ROM adapter idea, could you copy the ROM data to a section of RAM during initialization, and then use that copy?

As far as I know, a real 68000 also changes control signals on both rising and falling clock edges, and it's not something unique to the TG68 core.

[roglio]

Hi Steve, why do you do not share your project?
I own a DE1 board and it will very nice to play with it :)

[roglio]

Hi tc! I know you're busy with your real life but I (and I suppose a lot of other users) will really appreciate if you give some hits to this port. In your spare time of course! Please!