Announcement

Collapse
No announcement yet.

Virtual Motorola 68000 "m68k" Machine With Up To 3.2GB RAM Expected For Linux 5.19

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Eric a un avis
    replied
    Originally posted by SteamPunker View Post

    Maybe if Motorola had released the low cost 68008 variant a few years earlier. Alas.
    Out of memory, Sinclair was the single big-name computer brand using the 68008 in the QL. They could not bring it out early enough though, at that time it seemed like it took ages to come out, and quite buggy in the first version. A mythical machine though, notably with its specific tapes.

    Leave a comment:


  • Eric a un avis
    replied
    Originally posted by dlq84 View Post
    As mentioned it’s for emulation. In an emulator you may as well support virtual USB disk or SD-card for booting.

    Leave a comment:


  • lem79
    replied
    Originally posted by ayumu View Post

    A clean workaround would have taken a few lines of assembly code.

    Set the maximum fast ram in ExecBase to 1MB, then recalculate execbase's checksum and reboot.
    That would have been good to know, and amazing if someone was there to show my 16 year old self how to do that! This was before I even had a modem. How times have changed.

    Leave a comment:


  • ayumu
    replied
    Originally posted by lem79 View Post

    Actually I had a use case for this: A bug in a 68030 accelerator board for my Amiga 1200 which incorrectly detected a 1mb SIMM as 2mb, and would obviously crash when trying to allocate memory above the 1mb. What I'd do is load applications into the 1mb (like DeliTracker) and then kill the rest of the fastram address space with NoFastMem, which prevented crashes because of the OS trying to access non-existent memory, but it allowed those applications which were loaded into the 1mb to run fast (a lot faster, which was important for the multichannel sound players in DeliTracker, i.e. the 14Bit-Noteplayer). I got an 8mb SIMM not long after and no longer had to use the workaround.
    A clean workaround would have taken a few lines of assembly code.

    Set the maximum fast ram in ExecBase to 1MB, then recalculate execbase's checksum and reboot.

    Leave a comment:


  • F.Ultra
    replied
    Originally posted by stesmi View Post

    0x10000000 to 0x7FFFFFFF is 1792MiB, but you also have 0x08000000 to 0x0FFFFFFF, which is another 128MiB, and that can also be used for that iirc.
    Looking at the memory map in the specs http://www.devili.iki.fi/mirrors/hay...ocs/zorro3.pdf for Z3 memory it ends at $80000000 (page 16). But one thing that really impresses is that the entire spec is only 84 pages, today you wouldn't even get a spec for a single API call with some big name vendor in that tiny space :-)

    Leave a comment:


  • stesmi
    replied
    Originally posted by F.Ultra View Post

    The total hardware memory space defined by the Amiga Zorro III expansion bus specification is actually only 1792 MB so that is the hard hw limit.
    0x10000000 to 0x7FFFFFFF is 1792MiB, but you also have 0x08000000 to 0x0FFFFFFF, which is another 128MiB, and that can also be used for that iirc.

    Leave a comment:


  • reba
    replied
    Originally posted by Chewi View Post

    Great explanation! I still fondly remember this icon.



    I loved those icons.

    Leave a comment:


  • dlq84
    replied
    Originally posted by Waethorn View Post
    Didn't they remove the floppy drive code already?
    nope, its still there: https://github.com/torvalds/linux/bl...block/floppy.c

    Leave a comment:


  • DMJC
    replied
    Did anyone ever develop cd streaming for the Amiga? It blew my mind when I heard that streaming level data from a CD was only really invented for Crash Bandicoot on Playstation 1. It feels like the Amiga was the biggest collection of missed opportunities in the history of computing.

    Leave a comment:


  • lem79
    replied
    Originally posted by ayumu View Post

    That is a workaround for very early, buggy applications.

    The very first Amiga only shipped chip ram, and some early applications failed to request chip ram for memory that actually needs to be visible by the chipset, such as graphics data to be set up as display. Forcing all allocations to be on chipram would help these few, poorly programmed early applications work on any Amiga configuration.
    Actually I had a use case for this: A bug in a 68030 accelerator board for my Amiga 1200 which incorrectly detected a 1mb SIMM as 2mb, and would obviously crash when trying to allocate memory above the 1mb. What I'd do is load applications into the 1mb (like DeliTracker) and then kill the rest of the fastram address space with NoFastMem, which prevented crashes because of the OS trying to access non-existent memory, but it allowed those applications which were loaded into the 1mb to run fast (a lot faster, which was important for the multichannel sound players in DeliTracker, i.e. the 14Bit-Noteplayer). I got an 8mb SIMM not long after and no longer had to use the workaround.
    Last edited by lem79; 19 April 2022, 10:05 PM. Reason: Edit: clarity

    Leave a comment:

Working...
X