LisaList2

Advanced search  

News:

2019.06.07 fixed NChat for the "Curve" theme, will eventually move it to its own page and add it to the default theme as well. Other plugins are next. see post in the Meta board for details

Pages: 1 ... 8 9 [10]
 91 
 on: February 09, 2021, 11:18:12 am 
Started by blusnowkitty - Last post by stepleton
Lisa2 beat me to the punch. I counted the number of pins on the header end of the cable: you guessed it, 50.

 92 
 on: February 09, 2021, 11:15:29 am 
Started by blusnowkitty - Last post by Lisa2
My guess is that this is just SCSI drive ( looks like a Seagate ST-225N), that was stuffed in a profile case.  To complete the hack, the cable is a homemade Macintosh SCSI cable, most likely for connection to a Macintosh Plus.  I don't think the "SHIPPING FIXTURE "markings are relevant to the conversion. 

I am guilty of doing things like this back in the day, I hacked up a dead HD-20 in a similar way and put in a SCSI drive, used for years.  External hard drives were very expensive at the time, this was a way to save some money. 

Rick

 93 
 on: February 09, 2021, 10:54:12 am 
Started by blusnowkitty - Last post by blusnowkitty
https://www.ebay.com/itm/Apple-Macintosh-Lisa-Profile-External-Hard-Disk-Drive-READ-POWER-ONLY-SOLD-AS-IS/203273361249

Anyone ever seen anything like this before? It's a near-completely gutted Profile, just has the power supply and a hard drive of some description... Top of the case is stamped with "SHIPPING FIXTURE;" there's another ProFile that pops up from time to time on eBay stamped similarly but it appears to be a complete drive. The drive inside doesn't look like a 506, Widget, or even the prototype Nisha, but what is it? It's all one massive IDC pin connector that terminates in a male DB-25.

Very strange whatever this thing is...

ETA I also just noticed the seller has a YouTube video up of this drive. Since eBay likes to nuke YouTube links, here it is directly: https://www.youtube.com/watch?v=aYTKsoFYg8c

Anyone recognize this sound?

 94 
 on: February 09, 2021, 10:47:47 am 
Started by blusnowkitty - Last post by blusnowkitty
Cool, I've updated Art Department's entry on the list. Thanks!

 95 
 on: February 08, 2021, 10:09:28 pm 
Started by stepleton - Last post by rayarachelian
A handsome plan, but PRU0's code is driven by ~PSTRB, and if you don't ~PSTRB, well... that means PRU0 can't load $55 for you and PRU1 has to snoop the data lines to catch that $55 for itself. Oh well.

Cool story. Anyway, now what?

Yeah, exactly, you have to work around it, as you have. Fun times!

Maybe this is the kind of mischief that LocalTalk could get up to.

Indeed as it has the highest IRQ and could be tied up for quite some time depending on what data storm the network has going on.

I'd imagine "reasonable" timeouts would be on an order of 1-5s, but... that's pretty long.

Might be worth looking through these to see what the Widget does with the timeouts if you understand z80 assembly and can figure out the timings: http://bitsavers.org/pdf/apple/disk/widget/firmware/code/

 96 
 on: February 08, 2021, 08:58:51 pm 
Started by stepleton - Last post by stepleton
Quote
You could (should?) use PSTRB as a clock input to drive reading bytes from the Lisa to the Aphid's buffers? But I'm not sure if the rest of handshaking uses it or not, if any of it doesn't that probably wouldn't work well. i.e. the 55 and other handshaking values, i.e. any code reading from IRANH or writing to ORANH.

Yes, ~PSTRB is the only clock there is when the Apple wants to read or write more than one byte. It's not really negotiable. But...

Quote
I do recall the LOS ProFile code doing some writes to ORANH here and there

It sure does. This was the one bug I had in the first test of the Cameo/Aphid stack. I'm actually pretty proud of this --- when I first made Cameo/Aphid, I thought very hard about the software and hardware, and I checked, and double checked, and triple checked, and... to my delight, when I tried it for the very first time with my UsbWidEx, it just worked! That's my memory anyway; in real life I wouldn't be surprised if there were a few software hiccups that I just hadn't remembered. Nothing complicated though, what joy!

Unfortunately things weren't quite so rosy when I tried it with the Lisa (neither the boot ROM nor the Office System), and my mistaken assumption can be understood when you look at Dr. Schaefer's very handy logic analyser traces. Note all the places where it says "answers with $55" --- you don't see PSTRB there! I think I had missed this (so much for triple-checking!) and my recollection is that UsbWidEx does toggle PSTRB in those settings, which is what allowed it to work.

I'm not sure how dependable my memory really is here, but I do remember being annoyed by not having ~PSTRB on $55 for a silly reason. The TI AM3358 ARM-based SOC that powers the PocketBeagle single-board computer (and therefore Cameo/Aphid) is neat because it has two real-time I/O coprocessors called PRUs --- nifty, simple little RISC chips with very predictable timing. I had it all set up where only PRU0 would touch the data lines (and ~PSTRB and ~PPARITY) and only PRU1 would touch the handshaking lines PR/~W, ~PCMD, and ~PBSY. A handsome plan, but PRU0's code is driven by ~PSTRB, and if you don't ~PSTRB, well... that means PRU0 can't load $55 for you and PRU1 has to snoop the data lines to catch that $55 for itself. Oh well.

Cool story. Anyway, now what?

Quote
It may well be that if MacWorks is busy with something else, while a transfer is in progress that it would stop in the middle of sending bytes out for some time frame while it handles some other devices, such as the floppy or the serial port, etc. and if you time out waiting for PSTRB too early, you'd fall out of sync with it. So maybe increase that time to a lot longer. Maybe something ridiculous like 1s and then do a binary search dropping it lower by 1/2 until you see errors again and then back off a bit.

Contemplating the way the original ProFile is designed, and how it basically allows the Lisa to clock data in and out of the on-controller RAM at its own leisure, it seems like the correct timeout is... forever. I think most OSs are a bit more impatient than that, and even with MacWorks I could probably just bump up the timeout and call it a day, although you never know if someone's weird "helper" system modification or extension will grab an interrupt sometime and go to the circus for a few seconds. Maybe this is the kind of mischief that LocalTalk could get up to.

Maybe I will just bump up the timeout at first. But, given that I already have PRU0 set up to clock data in and out independently of most of the handshaking, it doesn't seem impossible to make it support an infinite timeout, so long as I have a way to interrupt it if it's time to move different data or move it in a different direction. I'll have to think about it a bit more.

 97 
 on: February 08, 2021, 04:46:40 pm 
Started by rayarachelian - Last post by compu_85
.... Added host serial port support ...

Sweet! I'll have to try it with the daisy wheel and Imagewriter!

-J

 98 
 on: February 07, 2021, 09:57:27 pm 
Started by stepleton - Last post by rayarachelian
It miiiiiiight be the case that my firmware is timing out too soon waiting for MacWorks to toggle the ~PSTRB line during reads and writes (e.g. here). If I had to guess, I'd say that MacWorks is more aggressive than some other operating environments about servicing interrupts while it's sending bytes to and from the drive.

Certainly possible.

If this hypothesis is right, then when my code gave up on ~PSTRB, it would stop sending bytes, but MacWorks would keep reading from the parallel port data lines. The nonsense values it would read would then have been what caused such a variety of trouble, especially if the values were code that it would then go on to try to execute.

Bumping up the amount of time my code waits on PSTRB seems to improve the stability of MacWorks Plus 1.1 quite a bit.

I'm not certain it's 100% fixed yet, but I think I've made progress.

That's great news, you're at least getting closer to a working solution.

So, I don't use the PSTRB line at all, AFAIK, it's automatically driven via CB1 (or CB2?) as writes are sent through ORA. Or rather, I should say my code doesn't depend on it in any way, but the effect is the same.

If writes are made to ORANH, PSTRB is not pulsed and the value just shows up on PA0-7 (assuming DDR=255 and RRW=write). However, from the point of view of the emulator, while its pulses are ignored, each write is handled like an event, instead, so there's no duplication, etc. Not sure it matters or not. You could disassemble the VIA 2 ISR and see what it does in detail and if there are any writes to ORANH (I think that's register 15 instead of 0 or something like that).

Most likely the VIA 2 ISR is just going to set a flag that the profile driver will pick up and act on instead of being used to transfer data.

But unless they've done some weird things manually - which could be, basically it should be pulsed once with each write to ORA.

Hmmm, I think perhaps one early change in LisaEm post 1.0 was to decouple the CPU clock from the rest of the system, including the VIAs. I wonder if it was working with MacWorks because it was pinned at 5MHz? It doesn't matter at all for LOS, but perhaps there's something in MW that depends on those having the same timings.

I do decouple the MHz rate for the CPU from the T1/T2 timers (as well as the clock in the COPS), perhaps that's an issue. But then how does the XLerator work? Hmm, maybe it does some modifications to that code as well.

You could (should?) use PSTRB as a clock input to drive reading bytes from the Lisa to the Aphid's buffers? But I'm not sure if the rest of handshaking uses it or not, if any of it doesn't that probably wouldn't work well. i.e. the 55 and other handshaking values, i.e. any code reading from IRANH or writing to ORANH.

I do recall the LOS ProFile code doing some writes to ORANH here and there, but not sure if MW does the same or not. I'm pretty sure it's when they're first talking to each other around the 01/02/55 handshaking stuff, but I think it's meant to leave the port with that value and reset the state machine.

It may well be that if MacWorks is busy with something else, while a transfer is in progress that it would stop in the middle of sending bytes out for some time frame while it handles some other devices, such as the floppy or the serial port, etc. and if you time out waiting for PSTRB too early, you'd fall out of sync with it. So maybe increase that time to a lot longer. Maybe something ridiculous like 1s and then do a binary search dropping it lower by 1/2 until you see errors again and then back off a bit.

 99 
 on: February 07, 2021, 08:44:11 pm 
Started by stepleton - Last post by stepleton
It miiiiiiight be the case that my firmware is timing out too soon waiting for MacWorks to toggle the ~PSTRB line during reads and writes (e.g. here). If I had to guess, I'd say that MacWorks is more aggressive than some other operating environments about servicing interrupts while it's sending bytes to and from the drive.

If this hypothesis is right, then when my code gave up on ~PSTRB, it would stop sending bytes, but MacWorks would keep reading from the parallel port data lines. The nonsense values it would read would then have been what caused such a variety of trouble, especially if the values were code that it would then go on to try to execute.

Bumping up the amount of time my code waits on PSTRB seems to improve the stability of MacWorks Plus 1.1 quite a bit.

I'm not certain it's 100% fixed yet, but I think I've made progress.

 100 
 on: February 07, 2021, 05:39:58 pm 
Started by stepleton - Last post by rayarachelian
Ray, do you find that the problems mostly come around when you try to work with the hard drive? In other words, does it run fine from a floppy drive?

With MacWorks, yes, absolutely. There was some bug introduced shortly after the 1.0 release, where upon returning to the Finder, it would crash, but that was fixed recently back around August with all the CPU fixes.

It now mostly works, though sometimes after installing to the hard drive, it shows a sad mac and other times it works. But not issues with the floppy.

Edit: For 1.2.8, I'm leaning towards rewriting profile.c and that widget.c code that rolled back as a FSM. I found some GPL C Finite State Machine generators on github, there's a few that take a yaml file that describes the states, inputs, and outputs for each state, and generate C code, since profile.c is a big ball of switch/case statements and annoying to debug. I'll likely reuse the code in profile.c in those states after generation, but it will be a bit cleaner.

If it turns out to be a timing thing where the guest OS wants to wait at minimum X ms, I'll likely patch the guest OS to get around the waiting and let it run at full speed.
But yeah, plans for 2.0 or possibly 1.2.8 is to use HLE to bypass all the block read/writes, but that will require more disassembly and reverse engineering.

Pages: 1 ... 8 9 [10]