General Category > LisaList2
Workshop
rayarachelian:
Yes, that's what I was pointing out it might be. It sometimes actually throws a bus error when the linker is invoked, other times it throws "Bad Intrin Patch Instruction" - and it's repeatable, it's not random, so re-executing the same link of the same object will cause the same result.
I don't know which opcode(s) are broken. It also breaks Tom's Mandlebrot application when zooming, and possibly is related to the scrollbar thumbs being wrong, and Desktop menu repeats. It's possibly a rotate opcode, but all the CPU tests I've done match a real 68040 off a NeXTstation turbo color.
So either I didn't find the right opcode, or perhaps the 68040 does something slightly differently from the 68000. Could be as simple as a status flag or an actual result difference, not sure. I've not been able to track down this elusive bug.
Tom and I thought it might be related to division opcodes, but that too proved fruitless.
I suppose I could port the test suite to say Xenix on a real Lisa, but I don't feel comfortable leaving the Lisa on for weeks at a time for it to go through millions of opcode tests like I did with the NeXT, I don't want to damage my Lisas, but if I could get a non-rare very common 68000, not 68010 or 68020, with a unix like OS and C compiler, I might try that and see if I can track it down. The NeXT slab was nice because they're fairly reliable and have ethernet so I could use NFS as the file system for storing the results of the tests to, and could telnet into it and watch it run, etc.
I suppose an old MacPlus might do, or an Amiga 500, but these too are really old and I wouldn't want to damage them either, not that I own either of those machines.
There's some old details about the CPU testing here: https://lisa.sunder.net/cputest.html
D.Finni:
--- Quote from: rayarachelian on March 12, 2019, 09:55:21 pm ---There's some old details about the CPU testing here: https://lisa.sunder.net/cputest.html
--- End quote ---
I read that whole page.
You said,
--- Quote ---The idea is to get the CPU core compiled on a m68k, then execute a single opcode with the three inputs (two register values + the CCR) on both the native 68k chip, and the Generator function, then compare the results in the output register and the CCR. If there's any difference, complain, then change the input values and try again, etc... :)
--- End quote ---
I don't see why you need to have the CPU core compiled and running on the 68K machine. Isn't it enough just to test all the CPU instructions on the real 68000 CPU, store the results, then run your emulated 68K CPU on whichever computer, and compare the stored results?
--- Quote from: rayarachelian on March 12, 2019, 09:55:21 pm ---So either I didn't find the right opcode, or perhaps the 68040 does something slightly differently from the 68000. Could be as simple as a status flag or an actual result difference, not sure.
--- End quote ---
I don't see how this could possibly be justified. The internal implementation of the 68000 instructions may differ, but how could the results differ and still offer 68K family compatibility? I had a Macintosh Quadra with a 68040 CPU and it could run old Mac software written for the 68000 just fine.
rayarachelian:
--- Quote ---I don't see why you need to have the CPU core compiled and running on the 68K machine. Isn't it enough just to test all the CPU instructions on the real 68000 CPU, store the results, then run your emulated 68K CPU on whichever computer, and compare the stored results?
--- End quote ---
Initially I thought to run just tests on the NeXT itself vs the Generator core. However, later I realized what I was actually after were the results of the 68040 itself and recorded the outputs as those are more useful. For example an emulated 68000 running on a 68000 would likely return results consistent with native code on the 68040 and would likely not differ. However the Generator core running on a SPARC, Alpha, x86_32/64, ARM, PowerPC, etc. might differ, so while that page says what it says, I did pivot to just capture the results and test externally.
--- Quote ---I don't see how this could possibly be justified. The internal implementation of the 68000 instructions may differ, but how could the results differ and still offer 68K family compatibility? I had a Macintosh Quadra with a 68040 CPU and it could run old Mac software written for the 68000 just fine.
--- End quote ---
Weird edge cases can happen between CPU cores of the same family. Intel is much worse than Motorola, but the fact is we don't know for sure. This is a contrived example, but the bus error exceptions on the 68000 differ quite a bit from a 68010 and a 68020 and 030 and 040 and the differences are handled in the system software itself. Also for example NOP has no effect other than to eat cycles and move the PC forward on a 68000. On a 68040 it has a cache flush operation. On the 68000 you can write self-modifying code, on the 68040 because of the CPU cache, you cannot and should force the instruction cache to flush, etc.
For example https://www.revolvy.com/page/Motorola-68010 mentions:
--- Quote ---The 68010 was pin-compatible with the 68000, but was not 100% software compatible. Some of the differences were:
* The MOVE from SR instruction is now privileged (it may only be executed in supervisor mode). This means that the 68010 meets Popek and Goldberg virtualization requirements. Because the 68000 offers an unprivileged MOVE from SR, it does not meet them
* The MOVE from CCR instruction was added to partially compensate for the removal of the user-mode MOVE from SR.
--- End quote ---
There were a number of bugs that I found in the BCD math modes of Generator, it's possible some of those were behaving actually correct Generator for the 68000, but when tested on the 68040 were marked as errors.
There are other weird edge cases to consider are for example, what happens if you do i<<33 or i>>33 where i is a byte, signed byte, word, signed word, long, or signed long? That actually produces different results on x86, SPARC, ARM than it does on m68k, and possibly will vary across different compilers too.
I'm not claiming the above are the exact cause for the linker emulation issues, but rather that I suspect it might be the case here. If I knew for sure, I'd be able to address the issue. and it might not even be something obvious. It could be any number of things that weren't tested, or were tested and passed, or some weird bug between two opcodes that exists only in certain cases, but not others. (Generator uses an instruction parameter cache as an optimization, I have seen certain issues with this before, which I've fixed in 1.2.7, but it did not resolve the linker/scrollbars/Desktop menu bugs.)
D.Finni:
--- Quote from: rayarachelian on March 04, 2019, 09:11:37 am ---The tags are well documented, the Lisa's File System isn't. I started to do that a long time ago, and @claunia finished the job. I have notes somewhere that I've been meaning to turn into a new version of the lisafsh-tool. Perhaps I should revisit that soon'ish.
--- End quote ---
I see in the Lisa Operating System 3.0 Reference Manual, page 2-3, text describing "Page descriptors" which are stored within each page (block) on disk. It says there are 8 components of the page descriptor, and then it lists them.
Is the page descriptor the 12 tag bytes for each block?
sigma7:
I've located some original Workshop Supplement disks (perhaps no longer in working order) and found so far:
Set 1:
* MacSupplement 1, Workshop 2.0, LisaDisk
* MacSupplement 3, Workshop 2.0, LisaDisk
* MacSupplement 4, Workshop 2.0, LisaDisk
* MacSupplement 5, Workshop 2.0, LisaDisk
* IMAGEWRITER 8/1/84, Pre-release, Workshop 2.0, LisaDisk (the above are 6 colour Apple labels, with text printed by a dot matrix printer)
* MacSupplement (6), Nov-84, Lisa WorkShop Disk
* MacSupplement (7), Nov-84, Lisa WorkShop DiskMy post-it note on the box suggests there was a disk 2, as well as "MacStuff 1" through 4, which rings a bell as being utilities etc. on Mac formatted disks, MacWorks 1.0 and MacWorks with LisaBug.
Set 2:
* MacSupplement #1, Lisa Workshop Disk, February '85 through #6
These have 2" x ?" die-cut office labels made on a DMP and cut about 2.75" wide.
Three are re-used disks with similar style labels underneath (I'm confident they arrived that way) reading:
* Mac <illegible>, (NON-BOOTABLE), Mac <illegible>, December - 84
* MacSupplement #6, Lisa Workshop Disk, December 84
* MacWorks, Lisa startup Disk, December 84
Set 3:
* 5/85 Workshop Supplement 1, Lisa Workshop Format, (c) May 1985, Apple Computer, Inc. through #3
* 5/85 Workshop 3.9 Update 1, Must be used from, Lisa Workshop 3.0, (c) May 1985, Apple Computer, Inc. through #2
* MacWorks XL 3.0, (c) May 1985, Apple Computer, Inc.(A couple of these are re-used disks with labels stuck over others; I'm confident they also arrived that way)
Let me know if images of any of these disks are a priority and I'll try to assist.
< < :P
Page 6 of
http://bitsavers.org/pdf/apple/lisa/workshop_3.0/Lisa_Workshop_Supplement_Ver_1.0_1986.pdf
shows the last draft of the technical document is 5/5/85.
I don't recall if there was an annual subscription for these or if one paid for each supplement when it was announced, but I believe the 5/85 version was the last of the Supplement versions available/distributed in general. After that, public distributions were made available through APDA. I don't know when the Apple Developer Program started in earnest; IIRC, I was not a participant until 1989 or so.
--- Quote from: D.Finni on March 01, 2019, 04:13:34 pm ---I have an article on Lisa Workshop Pascal for Macintosh Development and I'm missing the latest Workshop Supplement '86 disks that should have the latest libraries and interfaces for Macintosh Plus.
...
Anyone have these last Supplement '86 disks?
--- End quote ---
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version