Jump to content

68K Toolbox Project: Retro Serial Sync


Recommended Posts

  • 68kMLA Supporter
On 4/15/2021 at 11:10 AM, Crutch said:

all the GDevice stuff only appears on the 256k ROM.  The Mac II was the first machine that allowed multiple graphics devices.

No worries, that was no big deal. I just double-checked my assumption about the 128K ROMs all being for B/W only computers, as I wondered if I got ahead of myself, and maybe SE had the 128K ROMs (and it can do color with card I think), but no, it's a 256K ROM as well (my memory of Mac timelines is less than fuzzy). But in doing that just now, I found links to the photos people found in the ROM (in 2012?)... super cool. 

 

 

Link to post
Share on other sites
  • Replies 52
  • Created
  • Last Reply

Top Posters In This Topic

  • 68kMLA Supporter

Today's update: This was going to be so simple... DOH!

 

Ok, I didn't exactly thing this was going to be a simple project, but I didn't realize that the most complicated part wasn't going to be fussing with the Mac OS Toolbox. What I've learned (very painfully) is that the logic of "sync" combined with logic of serial transfer = ONE BIG LOGIC MESS. I started with a little diagram basically written on the back of a napkin (virtual bar though, thanks Covid). It was going to be simple. If file is older, ask for the latest from the other computer. Both computers were basically going to be equal partners after the sync started. Each would be responsible for comparing the other computers list of files to its list, and then asking for any files it needed from the other computer (via a queue). There was really just going to be 2 modes: "we are talking to each other about syncing" and "we are now sending file data back and forth". First thing I got wrong was that I didn't count on having to basically respond to every transmission from the other computer. If I didn't do that, the other computer might just keep on sending messages. Ok, so diagram gets more complicated. Second thing I realized was that the computers were getting into a race condition: if both computers wanted something from the other, they could both send a "give me that" message at the same time, and instead of getting back an "ok" message, they'd get a "give me that" message and be confused. So that whole design had to be redone so that now computer that starts the sync is the controlling computer, and basically just bosses around the other computer until the whole sync is done. It is responsible for comparing file lists both directions, for managing the queue, and for telling the other computer exactly what to do. 

 

I'm hopeful that this is pretty close to the final version of the finite state machine design for the app, but I haven't even really figured out the logic for deciding when to delete locally vs send the file to the remote computer, so who knows... 

 

For your amusement....

2045611507_SerialSyncDesignDiagramming-FSM-20210417.thumb.png.78d53a4455be5f2437fbc9432758663f.png

 

Each blob is basically a function (and a state). The green things in between are messages/inputs. The finite state machine code that controls what happens is generated in a Numbers document that looks like this: 

609269896_SerialSyncDesignDiagramming-FSMtabletiny-20210417.thumb.png.56b6bc0c6ccfa8b19342598a4ad637f0.png

The inputs are running across the top, and the states are running down the left. Anytime a state has an input it cares about, that's one of the blue (secondary computer) or green (primary computer) boxes you see. each of those boxes represents a handler function. 

 

All of that is pretty complex, but the resulting logic in the app's main loop is very simple:

new_fsm_state = global_app->fsm_event_[global_app->fsm_current_state_][new_fsm_input](the_dispatcher);

 

(the new finite state machine's state should be whatever the function mapped to Current State + New Input is)

 

Now time to actually do some new coding and work on filling in the red and blue circles... 

 

Link to post
Share on other sites
  • 68kMLA Supporter
20 hours ago, Frobozz said:

The finite state machine code that controls what happens is generated in a Numbers document that looks like this: 

 

You've built a metaprogramming tool for state machines in Numbers?  That's brilliant.

Link to post
Share on other sites
  • 68kMLA Supporter
On 4/16/2021 at 4:33 PM, olePigeon said:

Just an idea, kinda way out there, but:  if you implemented support for the Stac 9703 processor, you could also do real-time compression.  Would even work between a vintage Mac and PCs. :)

 

I don't know anything about them, and didn't find much googling them. Maybe a chip used in tape-based backup systems? No Macs have them onboard, right? 

 

On my to-do list is to incorporate some kind of compression option, for apps, as a way to make it faster, but mainly because you have to do something with them one way or the other, or the resource fork gets lost (leaving nothing). But I'm trying to keep the audience as wide as possible, given that the real audience is only people with 68k Macs, and only those that don't have an AppleTalk or ethernet network already working (because either of those is better). 

 

 

Link to post
Share on other sites
  • 68kMLA Supporter

Today's update: 

  • nothing good to report.
  • The finite state machine redesign works really well, so that's good. BUT... I hit a thing where some files are crashing the Mac Plus at start of download, and I can't see exactly what's going on. I have approximately 8 million debug statements in place, but I started to think it would be really nice to be able to look at it in a debugger. But THINK 7 needs 8 MBs to run itself and its debugger, and the Plus only has 4 mb. Tried with THINK 5, but it would crash the debugger on startup. (not to mention I had to do some icky workarounds to get THINK 5 to like the THINK 7 files). Also it took an ICE age to compile on the Mac Plus. 
  • there was a IIci on local craigslist advertised as working but stopping at disk-with-question-mark, but when I got there with a floppy emu in hand, it was dead. 
  • I started pulling machines out the closet to see what I could get working. Now, as anyone on these forums knows, this is a risky strategy. For the machines, but also for whatever project you had been working on before your new project of restoring-old-things-to-health kicked in. 
    • LCII: not sure how much RAM it had, but didn't matter: dead to the touch. General consensus on the LC/Performa forum seems to be bad PSU. 
    • PB165J: screen has been destroyed since I last put it into storage. I've never seen anything like it. it's like the plastic on the screen melted. Didn't try to power it on. Maybe harvest for parts though. 
    • PB170: hard drive was dead, but I had Stratos CF PowerMonster from 15 years ago I wasn't using any more (used to use that with the Plus, in an external enclosure). That got it up and working. But... 4 MB.
    • SE/30: 8 MB! Speedy! Works with exactly the same SCSI2D config as the Mac Plus! IT's GREAT! But... but... but.... the serial ports won't send anything. All the other wires light up, but not the send wire. ARGH! 
    • Classic II: turns out it was a Classic (so: slow). HD works. but... 4mb. 
    • And that is the end of my list of 68K machines (well, I'm not including the older-than-plus machines and the assortment of dead Pluses). 
  • As fun as pulling out the old machines is, and futzing around to get them working again (or not), it's not helping me get this project done. I think I'll try another on the local craigslist site, there is an LCIII up, and maybe it has enough memory, and maybe it runs. we'll see.. 
  • BTW, in case you are saying to yourself, "why doesn't he just debug in [name-your-favorite-emulator]?"... Mini VMac and Basilisk II do not feature serial port emulation (BII may for other platforms, but not for Mac). Believe me, I would have done that in a second. I tried to engage the Mini vMac guy, but he's not interested. I don't think BII really has an owner like that. I poked around a bit in the Mini vMac code, but I have no idea what I'd be doing, so that's a dead end too. Should have just made a calculator app! 

 

Link to post
Share on other sites
20 hours ago, Frobozz said:

 

  • BTW, in case you are saying to yourself, "why doesn't he just debug in [name-your-favorite-emulator]?"... Mini VMac and Basilisk II do not feature serial port emulation (BII may for other platforms, but not for Mac). Believe me, I would have done that in a second. I tried to engage the Mini vMac guy, but he's not interested. I don't think BII really has an owner like that. I poked around a bit in the Mini vMac code, but I have no idea what I'd be doing, so that's a dead end too. Should have just made a calculator app! 

 


I’d like to point out that pce-Mac-* will do you what you want here and probably massively speed up dev efforts for you if you’re interested. The biggest catch is, you must run Linux as the host OS. I’ll post the config settings and other requirements for doing bidirectional serial communication with Linux and pce today 

Link to post
Share on other sites
21 hours ago, Frobozz said:

I don't know anything about them, and didn't find much googling them. Maybe a chip used in tape-based backup systems? No Macs have them onboard, right? 

 

It's a popular chip with tape backup drives, but it was used in several hardware accelerated real-time compression cards for both Macintosh and PC (NuBus and ISA.)  It's the only one I know of that was used between different platforms.  You might have heard of Stacker, which was Stac's software/hardware combo for their chip.  They later released a software-only version.

 

Edited by olePigeon
Link to post
Share on other sites
  • 68kMLA Supporter
22 hours ago, camh said:


I’d like to point out that pce-Mac-* will do you what you want here and probably massively speed up dev efforts for you if you’re interested. The biggest catch is, you must run Linux as the host OS. I’ll post the config settings and other requirements for doing bidirectional serial communication with Linux and pce today 

 

Yeah, that's going to be taking the virtualization of this to a new level. To develop code for a 68K (real) Mac, I write the code on an ARM based Mac, compile and debug on a Mac emulator, which itself is running in a virtualized Linux environment. 

 

Looks like there now is an M1-compatible VM tool:

https://eshop.macsales.com/blog/72081-utm-virtual-machine-on-m1-mac/

https://mac.getutm.app

 

Is this accurate though? It only supports max 4 MB? That's too small to run THINK C++ 7 and debugger. 

Quote

PCE/macplus is a classic Macintosh emulator. It emulates a Macintosh 128K, Macintosh 512k, Macintosh 512ke, Macintosh Plus, Macintosh SE or a Macintosh Classic.

Emulated parts

Part Status
CPU A complete MC68000 emulator.
ROM An unmodified ROM image is needed.
RAM Memory configurations of 128K, 512K, 1M, 2.5M and 4M are supported.
Video Supported (512*342*2)
Sound Supported
Floppy disks IWM based 400K and 800K drives are supported. SWIM based high density drives are not supported.
SCSI Up to 7 SCSI harddisks are supported.
Serial ports Supported
Mouse Supported
Keyboard Supported
AppleTalk Not supported

 

Link to post
Share on other sites
  • 68kMLA Supporter
20 hours ago, Frobozz said:

Is this accurate though? It only supports max 4 MB? That's too small to run THINK C++ 7 and debugger. 

 

AFAIK, yes, it is an accurate emulator of those first three generations of compacts, and those did only support up to 4M.

Link to post
Share on other sites
On 4/19/2021 at 11:05 AM, camh said:


I’d like to point out that pce-Mac-* will do you what you want here and probably massively speed up dev efforts for you if you’re interested. The biggest catch is, you must run Linux as the host OS. I’ll post the config settings and other requirements for doing bidirectional serial communication with Linux and pce today 

 

Here is what I've got for making this work on Linux. I'm using Ubuntu 20.04.2 LTS but this is pretty generic so should work for anything. As you say, since you're on an M1 host Mac, you'll likely want to start with some flavor of Linux on parallels.

 

First install tty0tty. The instructions are at https://github.com/freemed/tty0tty. tty0tty is really simple to get working. This will give you a virtual serial port so you can run your "host side" serial application on Linux, without hardware, and have it work. Configure your host-side application to work with /dev/tnt0. As far as I know there is not an equivalent of this for recent versions of Mac OS, is one of the deciding reasons behind me choosing Linux.

 

Next install pce. This article is old but is still 100% relevant on installing pce: http://www.toughdev.com/content/2016/11/pcemacplus-the-ultimate-68k-classic-macintosh-emulator/. I have not been able to get pce to run on recent versions of Mac OS, but I suspect it would be possible to get working with a bit of fiddling and compiling it from source. If you didn't mind losing the virtual serial port you could maybe look into that... Anyways, in the config file for the whatever Mac you choose to run with pce, set the serial setting for one of the ports like this:

 

serial {
	port = 0 # port 0 is the modem port, use 1 for printer
	multichar = 1
	driver = "posix:file=/dev/tnt1" # the host application is communicating on /dev/tnt0, this could also be swapped for a real serial port as needed
}

 

Now, from inside the classic Mac emulator, any time you write to or read from the modem port, you will be actually operating on a virtual /dev/tnt1, which is connected to /dev/tnt0. Likewise if you run an application on Linux pointed at /dev/tnt1, any write operation will write to the Mac VM on /dev/tnt0 and so on... 

 

It's maybe a bit of work to get going, but you might find that it's worth it since it would eliminate all of the old hardware, etc. that you're dealing with at the moment and reduce things down to being purely a software problem. 

 

Link to post
Share on other sites
On 4/19/2021 at 2:02 PM, Frobozz said:

 

Is this accurate though? It only supports max 4 MB? That's too small to run THINK C++ 7 and debugger. 

 

 

Ah, yeah I guess that would end up being a problem for you unfortunately. I'm not sure if you're going for a particular dev aesthetic or anything, but if not, it's pretty straightforward to move the rest of your dev workflow to your host machine and ax the old compiler as well. The only problem I've run into there is, there is not any workable debugger (as far as I can tell) so you are stuck dumping debug log statements out one of the serial ports, with the PCE settings set up to write that output to a file.

Link to post
Share on other sites
  • 68kMLA Supporter
On 4/19/2021 at 4:02 PM, Frobozz said:

Is this accurate though? It only supports max 4 MB? That's too small to run THINK C++ 7 and debugger. 

 

 

Can you run it with virtual memory?

 

I’ve been wanting to run THINK C++ 7 with a working debugger including Macsbug in an emulator for a while.  (Mini vMac caps out at 4 MB, and BII can’t run Macsbug.). It occurred to me recently I might be able to get it to work under Mini vMac with VM, though I haven’t had time to try.

Link to post
Share on other sites
  • 68kMLA Supporter
21 hours ago, Crutch said:

I’ve been wanting to run THINK C++ 7 with a working debugger including Macsbug in an emulator for a while.  (Mini vMac caps out at 4 MB, and BII can’t run Macsbug.).

 

Have you tried a custom build of Mini VMac? I use a few, this is the one I use for dev:

-br 37 -t mc64 -m II -hres 1600 -vres 640 -magnify 1 -sound 0 -ndp 0 -speed 3 -as 0

 

Translation: Mac II, 1600x640, magnify on to start, 8x speed, 8 MB RAM (I'm not sure which of those got me to 8MB, looking back on it). 

 

That's enough to run 6.0.8 + THINK 7 + Debugger + 2-3 little applets (import file, export file, that sort of thing). 

 

I don't have macsbug installed on this system though, so not sure what your mileage would be there. And also, it's not a Mac Plus of course, it's a II, if that matters.

Link to post
Share on other sites
  • 68kMLA Supporter

Ah yeah sorry I misspoke. You’re right, I am indeed emulating 8MB on a Mac II but that’s not enough to do THINK C++ 7 dev under 7.5.5 which is what I want to do. 

Link to post
Share on other sites
  • 68kMLA Supporter

I haven't had a chance to do anything with a Linux VM. 

 

I did manage to get a working debug station going, thanks to help from folks here on the LC forum. Turns out you can power an LCII from an IDE drive utility thingie I already had, so behold this beauty:

818367259_SerialSyncLCII.thumb.jpg.b52798ac30e31f5b9cc0aa731fc2ae71.jpg

 

Maybe hard to see, but I basically just jammed the wires right on top of the wires from the PSU. And it works. Added SCSI2SD, and now I have a 6.0.8 machine with 10 MB of RAM, capable of running THINK 7 & debugger. Well, but... it turns out it is HEINOUSLY slow to start and end the debugger. Like 10-15 minutes. Which is just weird. SO I don't really use it. Also, the thing that was crashing, doesn't crash on this machine. So definitely thinking it's a memory/pointer/handler issue that exposes itself differently depending on how much machine memory is available. Setting that aside for a bit.

 

Progress:

- filled in some more of the bubbles in the finite state machine:  it can now push files to the remote. Previously only the pull from code was in place/working. That's actually a pretty big milestone. But much more to do... 

 

 

Link to post
Share on other sites
  • 68kMLA Supporter

What's fun about this project is that I get to learn new things little by little. This week I made my first CDEF. If you open an app with ResEdit and see a CDEF, it's a boring looking thing. Just code. What it is basically a custom UI Control. In this case, I had a Start (sync) and Stop (sync) button, and wanted to add a Refresh (file list) and a Delete (file) button. But text buttons take up quite a bit of space. And this is a Mac, it should be graphical, right? Well, turns out there is no graphical/icon button in the Classic Toolbox. (Maybe later? Carbon?). So you have to roll your own. 

 

I checked my regular sources:

  • Inside Macintosh and the other programming books I'd downloaded. Didn't see anything obvious
  • MacTech (really MacTutor) articles. A couple of articles on CDEFs in general, but without pictures it's sometimes a bit hard to understand what's going on. 
  • InfoMac archives @ U. Michigan in the development/source folder (http://umich.edu/~archive/mac/development/source/). Found PICTbutton 1.2, by Paul Celestin. Even had a little compiled demo app. Bingo! 
    • It turned out it did more than I needed/wanted, so I started out by trimming stuff out, and then realized it was storing state in the control's reference slot, and I was using that elsewhere to put IDs into, so I ended up kind of re-writing it, but that's fine, it was a good exercise. Also, not to oversell it: a CDEF for a control as simple as a push button is dead simple. 
    • I liked the simplicity of how the author set up associating the PICT IDs with the state, and having an equally simple concept for getting either color QuickDraw or B/W PICTs. 
  • After I built it, I found another example kind of CDEF that actually did a better job explaining how custom CDEFs work (just read the comments, it's well done). I would start here probably if had to do it again. http://fi.archive.ubuntu.com/info-mac.org/_Development/src/cdef-template-10.hqx

It was a little tricky to debug, as the CDEF can't really communicate very well, but I used SysBeep() to good effect, and got pretty good at switching between 2 THINK projects. You have a single .c file for a CDEF, with a separate THINK project, which just has that plus MacTraps library. Project type is "Code Resource". Instead of "Build Application", you get "Build Code Resource", and the result is a .rsrc file. You open that and your app's resource file, and copy the CDEF from it to your app's file. I gave mine an ID of 40. 

serial_sync_20210430_iconbutton_CDEF.png.b708ec4929a4d2aa1da9d280664a8b36.png

You set up a CNTL in your app's resource file that knows about the new CDEF. In Resorcerer, I just put in CDEF Res ID of 40, and it calculates the procID for me. In my scheme, I use minimum to be the value of the "button up"/unpressed state graphic, and maximum to be the value of the button down graphic. Those are for the color versions. B/W versions are (in this example), 1002 and 1003. Again, pretty much Paul Celestin's  scheme. I think I'll add a third state there, but same general idea. 

serial_sync_20210430_iconbutton_CNTL.png.ec5139d54fe882408d0bdca6ba2b57e8.png

 

Once you have the buttons configured in the .rsrc file, you can call them in your code with GetNewControl() same as you would any other control. 

// start sync button. Initial state: enabled
if ( (start_sync_button = GetNewControl(kCntlIconButtonStart, the_surface->window_)) == NULL)
{
	[[[ ERROR HANDLING HERE ]]]
}

SetControlReference(start_sync_button, (long)kCntlIconButtonStart);

 

Here's the B/W and color versions (I just realized I only used gray scale colors in my color version. Maybe I should start doing NextStep development)
serial_sync_20210430_iconbutton1.thumb.png.d0067b000ac8e280506fcae1c5f438be.png

 

serial_sync_20210430_iconbutton2.thumb.png.25a508b007af334e5a85785b2765fdbf.png

 

I'm not sure I like the B/W 'inactive' state, so I'll probably waste some more bytes on supporting a third graphic for each button, to have a dedicated disabled state. Overkill for the B/W, but I think the right thing for color. 

 

Pretty happy with how it turned out. Feels like a nice warm up for an upcoming task of creating a custom LDEF (list definition). 

Link to post
Share on other sites
  • 68kMLA Supporter

Minor update:

  • I modified the CDEF to have 3 pre-generated graphical states (6, because B/W provided separately from color):
    • Active, button not pressed
    • Active, button pressed
    • Inactive
  • I think the inactive representation is better now if you are on a color Mac. more what you would expect (err, right?). Visually, nothing changes for B/W Macs.serial_sync_20210502_iconbutton.thumb.png.3be430958039151aeb24e80a5f1f70f3.png
  • I meant to mention the other fun part here of this icon exercise: finding a graphic program to make the icons with. I tried SuperPaint, and quite liked it, but it didn't handle color (I believe a much later version did). I ended up with Cricket Paint, which I had never heard of before, but it's quite interesting. I don't fully understand what all the modes do, but I've been able to do what I need do, and it's got quite nice gradient support, and some interesting looking mix modes. I did a lot of web graphics back in the 90s with MacroMedia's FireWorks, which I really loved. It was kind-of-vector, but very pixel-output driven, a concept that really worked for me. But a generation of Mac too new for my current project. Anybody have favorites for 68K Mac graphics?
    serial_sync_20210502_iconbutton_cricket.thumb.png.8004aa85744d1a864aabb9518c667bf3.png
  • The only bummer with the icon buttons is the app size has swollen overnight by 50%! It was 95K without any icon buttons, then 130K with the 2-state buttons, and now 150K with the 3 state buttons. It's all in those color buttons. I don't suppose there's a sparse color table option I could use? It's not like I'm using a ton of colors. 
    serial_sync_20210502_iconbutton_bloat.png.85d123a1d00353658e35a33f08ce63c9.png
Link to post
Share on other sites
  • 68kMLA Supporter

I would normally expect about 1K (I think there is some compression involved so the size isn’t constant?) per 32x32 cicn, so if you have a bunch size can grow fast at this scale.  However those look smaller so I am surprised they take up so much space.  In ResEdit you can choose the 4-bit color palette from the menu then choose “Recolor Using Palette,” see if that helps?

 

If you wanted to be super space efficient, I would just include cicns for the blank button, then 1-bit ICONs for each button “icon” and overlay that on the respective buttons with srcOr before drawing on-screen, either in black or (for dimmed buttons) RGB gray.  You would lose the trash can gradient but I am not sure that matters.

 

Edited by Crutch
Link to post
Share on other sites
  • 68kMLA Supporter

ah, err, umm, so it seems that what really happened was I replaced one of my files on the "build Mac" at some point in the development of the icon button, and forgot that on the build Mac I had been un-defining the macro for 'debug' statements. So they were all getting written out again. And that's actually the biggest chunk of that data. the original 2-state icons accounted for 95k->102K (about 7k). Then 30k of debug statements started getting compiled in. Then the 3-state icons bounced it up to 150K (+18k I guess). It's down to a svelte 116K again after turning off all levels of logging. 

 

Quote

// turn debug mode on/off
#define LOG_LEVEL_1        // errors
#define LOG_LEVEL_2        // warnings
#define LOG_LEVEL_3        // infos
#define LOG_LEVEL_4        // debug level info for programmer

 

The only reason I actually noticed was that I started getting data segment too large errors in THINK. I haven't studied that carefully enough yet. I think I only get 32K of data, unless I do 'far' data or whatever. If these were permanent in nature, I believe the right thing would be to make them into STR's in the resource file, which I think you get "for free" in terms of 32k cap. Am I about right in that thinking? 

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...