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 [2] 3 4 ... 10
 11 
 on: September 19, 2021, 07:02:34 pm 
Started by AlexTheCat123 - Last post by blusnowkitty
As much as I appreciate the hardware and software engineering effort and as much as I like puns and wordplay,

Uh, really?

 12 
 on: September 19, 2021, 05:56:19 pm 
Started by AlexTheCat123 - Last post by stepleton
Gotta be honest... call me thin-skinned if you like, but being close relations to a few folks who work in child welfare, I'm not a big fan of the name. I'm unlikely to have much to do with it as-is.

 13 
 on: September 19, 2021, 05:48:47 pm 
Started by AlexTheCat123 - Last post by AlexTheCat123
I just uploaded the source code and a description of the device to GitHub, so feel free to check it out if you guys are interested!

It still doesn't work with the Cameo/Aphid, so I'll have to keep looking into that issue.

By the way, I tried using the Arduino to emulate a ProFile and it kind of worked, but it just couldn't always keep up with the strobe pulses from the Lisa.

Let me know what you guys think and if you have any suggestions!


 14 
 on: September 14, 2021, 06:27:02 pm 
Started by rayarachelian - Last post by rayarachelian
Back into the Storm: A Design Engineer's Story of Commodore Computers in the 1980s by Bil Herd

Just finished his book, see: http://www.c128.com/new-commodore-book - you can find it at the usual places.

Really really good read. I mispent the best years of my youth on the machine he helped build, the C128. Was a really fun read, far more Pirates than Navy than you'd see at Apple.
I wish there was a similarly written book about the history of the Apple Lisa written by one of it's builders in the same style as this book.
If you're a fan of 1980s 8 bit computers, this is for you.

 15 
 on: September 09, 2021, 09:53:46 pm 
Started by blusnowkitty - Last post by blusnowkitty
Thanks Rick! I'll try rebuilding my DMP cable to see what happens. Interestingly there's still an error in the text on Apple's website - they omit Pin 14. I see in the printed document that Pin 14 on the Lisa is GND, and that gets tied to BSY on the Centronics side. Although strange is that Tom's adapter pinout leaves BSY floating and it still works for him, but he's also got a proper 1080A.

I think my next step here is going to be breadboarding up a bunch of LEDs in between the Lisa and the printer just to make sure data is flowing to the printer. I'm also wondering if the 1080A driver sends something that the 3852 doesn't like? On the other hand that shouldn't be the case. The Generic / Text Only driver in Windows does make it print.

 16 
 on: September 09, 2021, 04:16:38 pm 
Started by blusnowkitty - Last post by Lisa2
Does anyone here have an original DMP cable and would they be able to verify the pinout?

The pinout for this cable ( 590-0042-B) is correct.   See attached photos.  Also note that when I played with this in the past I did not connect pins 16 or 35 on the printer side ( I don't remember if this helped or not).  Maybe you can try this on your cable.

Rick


 17 
 on: September 09, 2021, 01:40:49 pm 
Started by Lisa2 - Last post by stepleton
Thanks for trying it out! I guess that settles it. Cameo/Aphid will just be slower than the X/ProFile for now.

In a read request, there is basically one likely place for an Apple parallel port hard drive to be slow, and that's when it's getting the data ready for the computer to read back. Once the hard drive says "ready", the computer sets the pace, and there's no reason to expect that the Lisa would treat any hard drive differently at that point.

So the place to look for speedups on read is at the point where the drive marshals data to be read into the computer. In Cameo/Aphid there's definitely some room for improvement in the higher-level side of things. (Cameo/Aphid's programming is split into two parts: fast lower-level I/O that runs on these dedicated TI coprocessors that the PocketBeagle has, then a slower high-level Python program that runs on the ARM.)

While Cameo/Aphid is running, the entire drive image is living in a memory mapped file, so it's starting off in a place where it can be accessed very rapidly. It's simple to access a block --- you just pull the right run of bytes out of an array.

But then it has to copy the data over to the PocketBeagle's speedy I/O coprocessors --- and ah yes, this is probably a big reason for why reads are slower. It can't just do a copy --- it also has to compute and interleave the parity bytes* for all of the data bytes on the fly. This line would probably be WAY faster in any common compiled language. Once it does that, it has to do that copy, but it does it in three chunks (not two) because of that 512-byte limited internal I/O that I mentioned: we have 2*532 bytes to copy given the parity bytes.

In a way I'm relieved, since there's probably a lot of low-hanging fruit to get more speed. I'm reluctant to move away from Python since that's what makes the "magic block" plugin facility so easy to program. (This is the system that powers the hard drive image selector.)

But I probably won't try to do anything unless I hear that running twice as slowly as an X/ProFile is a problem :-) I'm guessing (hoping!) that Cameo/Aphid will still smoke a ProFile or a Widget, but the main setting where I could anticipate an issue with the speed as-is is if you're trying to watch a video.

Thanks for doing this investigation! I'm still annoyed that the termination resistors aren't a general solution. More development is required to see if the TXS0108 chip option can be reliable at the end of the internal cable. I'll update the Cameo/Aphid GitHub page soon to say that it's not a sure bet.


* ETA: Parity bytes? Well, we only use one bit of each byte, but we still use a whole byte for simplicity.

 18 
 on: September 09, 2021, 12:11:16 pm 
Started by Lisa2 - Last post by Lisa2
As a followup to my post yesterday:

1. I did confirm the SD card in the Aphid I used for test was a 16Gig UHS speed class 1 ( equivalent to a speed class 10 ).

2. My interface uses TXS0108s and 100ohm resistors

3. I did try to test my real 5M profile, but while it was working last weekend, it was not cooperating last night.  Those things are quite temperamental.

4. Tested the same X/Profile on both the internal 2/10 port and using a Dual Par Card.  The end result is that Dual Par Card is faster than the internal port in this very un-scientific test.  Long, un-professional video of the testing here:

https://youtu.be/63BF9FbOylU

Rick

 19 
 on: September 08, 2021, 06:53:59 pm 
Started by blusnowkitty - Last post by blusnowkitty
Does anyone here have an original DMP cable and would they be able to verify the pinout? I'm now curious if the schematic on Apple's website is correct - building the cable according to the document seems to have an error where it says Pin 21 on the Lisa should go to Pin 13 on the Centronics. However Pin 13 on a Centronics is SELECT, where Pin 31 is the RESET line. This seems to be backed up by Tom's work in the LisaList1 thread saying Lisa Pin 21 should go to PC Pin 16 which is indeed the RESET line on a PC-style cable. Once I moved RESET from 13 to 31 I started seeing the printer resetting on power-up. However I'm still not getting any output from the printer even after moving BUSY from 11 back to 10 (ACK) on the Centronics.

 20 
 on: September 08, 2021, 06:02:52 pm 
Started by Lisa2 - Last post by rayarachelian
Don't get misled. That "1.25MHz speed" thing is about the T1 and T2 timers that are inside the VIAs, which can cause an interrupt, or be used to generate a square wave output, etc. It's not about the transfer rate to/from a ProFile or Widget.

"625K bytes/second maximum data transfer rate is pure bullshit. They got to it like this: 68000 at 5MHz so 5,000,000 cycles/second. Each memory access is 8 cycles. 5,000,000 / 8 = 625,000 or 6.25KB/s.

However that's a lie. If you have a tight 68000 assembly loop that reads from port A on that via, and then turns around and writes to memory and increments an address register, you need at least two memory accesses (each 8 CPU cycles), one for a read and one for a write.

But wait! There's more! The 68000 doesn't really have a cache (well it has the IR register, which is a single word, so might as well have none), so it needs some bus cycles to read those opcodes, and then, to execute them.

The smallest opcode can be read in a single shot (2 bytes/1 16-bit word) - so 8 CPU cycles.

So if you use register based addressing, indexing you can do something like this:

Code: [Select]
       LEA.L  VIA_portA, A0
       LEA.L  BUFFER,A1
       MOVE.W #512+20,D0
loop:  MOVEP.B (A0),(A1)+
       DBRA D0,loop

This guy MOVE.B (A0),(A1)+ will take at least 24 CPU cycles, likely more. 8 cycles to read the opcode, 8 cycles to read from the VIA port A (IRA), 8 cycles to write to the port's data to memory (A1), a few more to increment A1 +. Then, DBRA will take yet at least 8 more cycles just to read the opcode, likely more for the decrement of D0.

So, right off the bat you're looking at minimum 32 cycles.

On top of that, half the bus cycles are used by the video state machine, during which time the 68000 is just sitting there waiting. Sure, it could perform internal operations, but that's unlikely as there's no cache. So you're already starting with [ 5,000,000 cycles/sec / 2 (video state steal)  / 32 (cycles for those two instructions) ] at the absolute minimum.

So doing that division gives us something like 78.125KB/s at the absolute best case. And yes, I cheated, I was lazy and didn't assemble this and look up each opcode generated in the 68000UGM to see the exact cycle. Most likely its more cycles than I said, so slower than that 78KB/s - possibly even as slow as half of that.

Sure you can play tricks like loop unrolling (which LOS 3.1 does) or whatever, but there is some limit that you can't go past.

Perhaps if they had rigged up a DMA controller it might have gotten closer, but still, it would take about the same number of cycles while the DMA controller does its thing and the 68000 is waiting for the bus. You'd need to rig up a separate bus out of the way of the CPU to the DRAM and tie it into the DRAM-refresh to get that fast - that is instead of using half the cycles to just refresh the DRAM (which is the other half of the purpose of the video state machine) you could have the DMA controller push data from the ProFile directly to a buffer setup by the OS in RAM. Which is really hard to do.

The Mac does something similar with its video state machine, but uses faster DRAM so they can go the full 8MHz and also do the DRAM refreshes while the CPU isn't using the bus (I think it uses !CLK vs CLK so both high and low clocks are used) - Steve Chamberlain had a nice writeup on this when he was building his Mac clone: https://www.bigmessowires.com/category/plustoo/ or here https://www.bigmessowires.com/category/68katy/  - but I remember he had another with the bus cycle timings and what not that I don't see right now.

The Lisa actually alternates between 8 cycles for the CPU, and then 8 cycles for the video/DRAM refresh - somewhere in the Lisa HWG they show this with all the bus cycles 0-7 for CPU, then 0-7 for video. That's why it's much slower. So it's closer to 2.5MHz in reality.

So tl;dr there's no way to get anywhere near 625KBPS. I'll go away and shut up now. :)

Pages: 1 [2] 3 4 ... 10