Closed dirkwhoffmann closed 5 years ago
I already like your approach. πππ
What's new? Paula got a brand new disk controller and can read in whole tracks now. She's pretty happy, but another problem came up. After reading the first track, she constantly decides that the disc is no good and asks for another one π€¨.
I've tracked down the issue to these lines of code
1207: E fe85a4: 2014 : move.l (A4), D0
1208: E fe85a6: b0ba fe74 : cmp.l (-$18c,PC), D0; ($fe841c)
1209: E fe85aa: 6654 : bne fe8600
The value read in line 1208 reads back as 0x4447D180, but Kickstart expects 0x444F5300.
Paula says, it's not her fault. I didn't believe her at first, but further investigations have shows that she might be right. The track data in memory is 100% correct.
Agnus, however, claims to have seen somebody looking like this π―:
Apparently, this guy has stolen 0x4447D180 - 0x444F5300 = 491904 from my checksum π.
Anyway, he shouldn't feel too save. I've already checked the contents of A4 which is 0x5C40. This address is neither written by the CPU nor by DMA. The third component writing to memory is the Blitter, so I expect him to hide there. We'll see ...
Gotcha π. He was hiding inside the Blitter's barrel shifter. Next step will be to remove the hundreds of printf statements that were added to track him down.
Seems to be time to teach Denise how to draw hires pixels π€
Wow it loads into CLI. Text drawing looks the same as in your first session with the guru meditation in logbook for version 0.1.
In a early version when omega was still zorro ;-). It had this too, look here at the guru picture http://eab.abime.net/showthread.php?t=90316&page=2
Text drawing looks the same as in your first session with the guru meditation
Yes, that's because Denise has no hires drawing code yet.
BTW, if anybody thinks about using the C++ STL library for time-critical stuff... just forget about it π€¨:
Fortunately, I'm only checking for breakpoints when the inspector panel is open. But hey, come on, 50% of computation time is spend in code that iterates over an (empty!!!) map container? That is ridiculous. I definitely need to port my breakpoint table back to native C π.
The drive head logic (which rotates the disk and reads a byte) and the DMA logic are now decoupled. When the drive motor is on, a DSK_ROTATE event is scheduled periodically in the secondary event table. When this event triggers, a byte is read from the drive and stored in a FIFO buffer. The DMA part checks the FIFO, and if at least two bytes are present, a single word is shuffled into memory. The DSK_ROTATE events are schedules with a period of 56 DMA cycles (which corresponds to a drive rotating at 300 rpm if my calculation is correct).
If you wish to view the disk controller in action, you can do so in Paula's inspector panel now:
Unfortunately, I didn't remember how loooooong it took on a real Amiga to load from disk. Hence, I guess it might be best to implement the turbo drive stuff first.
Getting better π ...
It seems to be working, but I have to rethink the drawing architecture. Scheduling separate drawing events (independent of display DMA events) seemed like a good idea at first, but my feeling is that it's overkill and slows down emulation unnecessarily.
How beautiful. My god, its full of clear sharp and thin lines and characters ... (Kubrick, 2001 odyssey in space)
π€
Does the Amiga have a build-in internal clock??? I thought that was a feature of the A500's slow Ram extension card π€...
BTW, Denise seems to need glasses. She squints a little.
My Amiga1000 does not have a clock. As far as I remember the first batches of A500 did not have them either. But you could expand them to have one, you installed the battery powered clock in the so called "trap door". A friend of mine did so. Later revisions of A500 and for the A2000 I don't know...
2-JUN-87 (time machine π, let it stay there don't move forward in time. In retro we trust.)
My mistake (I should have read what's displayed in the CLI window). I am booting a A2000 workbench disk and the A2000 has a buid-in real-time clock. I guess the error message vanishes if I boot from a A500 workbench disk.
I'm fairly certain that the A500 never had a clock: I seem to remember most of the trapdoor RAM expansions from the time also came with a battery-backed clock, which suggests it wasn't something built in.
However, this page suggests that the very last revision of the A500 did have a clock?
@KenDFish the page you found says only A500 Plus had one on the mainboard. But in contrast even the last Revision8 of A500 had a missing clock circuit, the page says.
Yes, my Amiga 2000 has the real time clock...but the battery is gone.
Rechargeable barrel type battery . Two models (two and three pins) are available. This battery type is present in some Amiga computers as the Amiga 500+, Amiga 3000, Amiga 4000 or Amiga 2000, in some of their accelerators and memory cards such the A501, and in other retro computers and a vast of old hardware devices. New production (not from old stock).
Now, turbo drives are working. They can be configured in the hardware preferences:
However, the speed improvement is not that dramatic. Loading the workbench with a standard drive takes 55 seconds. Loading with an "unlimited" drive takes 25 seconds. Hence, disk speed is not the only bottleneck. There is a lot of stuff going on in track disk device that needs to be done while booting (MFM decoding etc. etc.).
The "Enable warp mode during file transfers" feature is yet to come (it can be selected in the emulator settings, but has no effect yet). The issue here is: If I enable warp mode only while DMA is on, it wouldn't have much effect (there would be no benefit over selecting an "unlimited" drive which essentially does all DMA immediately). Maybe, one could enable warp mode as long as the drive motor is on π€. This would really speedup things further.
So an option about real-time clock has to be added, or will it be automatically set if Amiga 2000 or any expansion ram card will be selected ?
If an A2000 is selected in the hardware preferences, I plan to automatically enable the "RT Clock" checkbox and grey it out. If an A1000 or A500 is emulated, I plan to let the user choose if he wants to add a RT clock (independent of the selected Ram extensions).
Implementing the RT clock is easy. I found the necessary information on eab:
http://eab.abime.net/showthread.php?t=31907
The forum post contains a link to the data sheet of the Oki MSM6242B chip which explains all details.
Real-time clock was an easy exercise π.
The harder thing was to get the display geometry right (there is some complicated interplay between DMA timing and pixel generation). Although it looks OK now, I believe that it's still not accurate. I'll investigate this further when I am able to write test programs inside the emulator.
Bad news from the upscaling team (my alter ego).
Now, as I can draw hires textures, I am able to test my super cool dynamic in-place xBr shader. It is dynamic, because it can distinguish lores and hires parts in the texture. The key idea was to apply the xBr algorithm only on the lores parts. Unfortunately, this idea has to be jeopardised as the two right most pictures show. In short: dynamic xBr does not work.
I expect to get better results with EPX + xBr, but this experiment has low priority for now...
Does anybody know how the Amiga detects if fast Ram is available?
I know that fast Ram it is mapped between 0x200000 and 0x9FFFFF, but when I boot the Amiga, it does never access one of these memory cells. Hence, auto-detection must work differently. π€
Don't know whether it helps but... I know that for the A1000 you could add memory to the front trapdoor expansion by wiring memory chips on top of the existing 256k (kind like piggy pack). This was of course not the offical standard way by commodore. But it allowed you very cheaply to have in sum 1MB. The extra 512k which was soldered on top of the existing 256k was no real fastram, effectivly due to the piggypack soldering I think. But as I remember these guys who did this had to call a special addram command from CLI. Then you had the 1MB amount of memory available. This type of cheap memory expansion was not autodetected at least in KickV1.2. I am not sure about Kick V1.3.
not much can be found about the addmem command on the internet here I found a link about addmem command
I think FastRam is detected via the Zorro II auto-config mechanism. I've added the config space to vAmiga's memory table, but it is not functional yet:
There is some decent documentation about the Zorro III standard out there, but I didn't find specific details about FastRam integration (each external device recognised itself with some special flags, vendor IDs, serial numbers etc.).
Now, Fast RAM presents itself as a Zorro II extension card to the Amiga.
I've took the flags, vendor, and serial parameters from the Verilog implementation of this nice hardware project:
https://github.com/PR77/A500_ACCEL_RAM_IDE-Rev-1
It seems to work. Kickstarts maps my virtual Zorro device at address 0x200000 (this is where Fast Ram usually resides) and the Workbench seems to accept the new RAM. Here is vAmiga after booting with 512 Chip RAM + 512 Slow RAM + 1024 KB Fast RAM:
I was briefly looking at UAE, too, but I did not even find the place where Fast Ram extensions are handled there π€.
Wow great. What an imense amount of memory. Quite unaffordable to buy in the ancient times 1985...
This Amiga seems to be very happy now ! In the graphic above this image, yours vAmigas Adress-Inspector showed 8192KB. Is it not possible to give it the full 8 Megs of fastram via Zorro II ?
vAmiga with 512 KB Chip RAM + 512 KB Slow RAM + 8 MB Fast RAM.
Must have cost a fortune back in the days.
8 MB is the maximum size for Zorro II Amigas. The newer ones (ECS) support Zorro III which can handle devices up to 1 GB.
π this is literally unreal. What a huge memory this Amiga has, must be enough to hold 3 modern jpegs at once. I even could not afford the extension to 1024kb in those days 1985-1987.
November 1989 - Β£79 (equivalent to Β£193 now) for 512K , and that's "low cost" !
On the left, they offer an A-MAX Macintosh Emulator for Β£129 π. So we get the Mac back by installing this inside vAmiga? So cool π.
What about a βI am richβ checkbox selector in vAmigas config? π No Dirk donβt. Just a joke.
Great ! Where can I download this VAmiga version which loads the Workbench ?
Where can I download this VAmiga version which loads the Workbench ?
There is a small problem still. vAmiga does not draw any sprites, so there is no mouse π. Without a mouse, fun with the Amiga is a little limited π.
Hi @mortinus , that is easy. Just download XCode, open it and it will ask you whether you want to download a project from a repositiory. You give XCode the following URL https://github.com/dirkwhoffmann/vAmiga.git Xcode will download the project for you. When it is done, you only have to press the play button and vAmiga will start.
Yesterday I bootet my Amiga Development disks. It did so successfully but there is still no mouse and no keyboard ... but nevertheless it is some fun... ;-)
... I will try :cry
...and to make a stand alone app ?
To make a stand alone app, choose "Archive" in the build menu. Xcode will build vAmiga (with compiler optimizations on) and display a window. In the window, select "Distribute App" and then something like "Save to file" or "Export to file". That's all.
Xcode is a great help for debugging, because it lets you see all debug message in the console window. Furthermore, if the app crashes, it directly jumps to the "bad line" in the source code.
XCode is huge, and I only have a 128Gb SSD. Is there a way to slim/reduce it down a bit, cutting off something useless to compile the VAmiga?
As far as I know, there is no stripped down version of Xcode available.
I'll upload a vAmiga binary once I get rudimentary sprite support working.
For information about sprites, a lot of smart stuff from smart people can be found here:
Coming closer. I can already see the pointer in the (updated) inspector panel. The DMA part seems to work π.
Time to teach Denise how to draw this thing ...
I've also invented a new software development approach which I'm gonna call "inverse prioritising". It's core idea is to postpone the most import things as much as possible.
I completely forgot that I wanted to develop this project using my new software engineering method (patent pending). To be honest, during the last weeks I did fallback to my old way of working which was to do the important things first π.
So I immediately stopped working on Denise and made the GUI panel a little bit nicer. BTW, the mouse pointer is now pointing in the right direction (I completely forgot how the mouse pointer looked like. It's a long time since I used a real Amiga).
Now, we need to make it move π€¨...
Basically it is one of the most colorful and modern looking mouse pointers of computer history. Click here to judge and compare yourself.
Some tounges even say, it has been designed by Andy Warhol the master of art himself.
Now, the mouse pointer can be moved.
However, Iβm not sure if it was a good idea to implement the mouse, because it reveals that there are tons of bugs inside vAmiga π.
The most severe one is that disk DMA does not terminate when the Workbench is opened. As a result, the Amiga becomes unresponsive, because it waits for the drive to finish π€¨. Sprite drawing doesnβt work correctly either as the screenshot shows π. Furthermore, I had occasional crashes on startup π.
I still uploaded a version, because Mortinus asked about it:
http://www.dirkwhoffmann.de/vAMIGA/vAmiga_0.2b1.zip
If you run that version, you can disable and reenable the Mac mouse by pressing Cmd-i (same as in VirtualC64).
Anyway, itβs good to know that the least important thing is working well: The new sprite debug panel. Maybe I should make it editable... π€π
Astonishingly computer mouse pointer iconography in general has been more or less static over the time. Every other aspect of GUI has visually changed enormously compared to mouse pointers.
MacOs 1.0 back then in 1984
Mac Mojave now in 2019
Windows 1.0 back then in 1985
Windows 10 now in 2019
AmigaOS 1.0 back then in 1985
AmigaOS 1.2 now in 2019 in vAmiga
I always asked myself: When this "thing" comes to live, will it be evil? π€
The answer is yes. I've created a monster π
First time without a read/write error.
BTW, when opening a disk in the workbench by double clicking the disk icon, Kickstart writes back the root track π³. Isn't that stupid or am I missing something? π€
Time to focus on unimportant stuff again. The ADF mounter got a new look:
If someone really wants to examine disk data, he can push the disclosure triangle (or simply resize the sheet with the mouse π):
Let's try something new. Why not insert a blank disk via menu Df1 -> New Disk -> Blank ... π€
Indeed, Kickstart recognises the disk in Df1 π:
Now, let's format that thing... (I had to Google how to do it, because I've completely forgotten how to operate the Amiga in the years that passed by π€).
Uhh, now it gets scary π¬...
Good to have warp mode which makes formatting pretty fast...
Wow, it terminates without displaying an error. vAmiga is getting less evil π€€.
There is also an option to insert a pre-formatted disk (formatted with OFS or FFS). The catch: It won't work π...
Now that vAmiga can display the startup screen, it's time to set up a new milestone. The next objective will be to load the workbench. However, based on my experience with V0.1, I am going to adjust my software development approach a little bit.
Originally, I started the project by reading the HRM and inspecting the existing UAE / SAE code. Now, here is the thing:
For all emulators I have seen so far, there is a strict reciprocal relationship between comprehensibility and compatibility. For this reason, I have abandoned the idea of looking up most details in UAE / SAE at this early development stage. In general, you can imagine UAE as a big bunch of millions of if statements (that are not always so cleverly named). Since my head is small, this big pile just doesn't fit in.
Therefore, I will take a different approach for V0.2. First, I am going to make my emulator functionally compatible to Omega and try to improve compatibility afterwards (by peeking into the source code of WinFellow and SAE). I already did this with the Blitter and it saved me a lot of development time (with the drawback that the Blitter is far from being timing-accurate yet).
In preparation for V0.2, I already did some groundwork. E.g., the event handler got a disk controller slot where periodic events are scheduled for rotating the disk. These events are not really utilised yet (because Omega doesnβt emulate it that way). Later, they will be used to fill a FIFO buffer in order to decouple the DMA stuff (which happens inside Paula) from the drive head logic (which is part of the drive of course). The FIFO buffer is already there, but hasn't yet been activated.