memory.mu4

| This file is part of muforth: https://muforth.dev/
|
| Copyright 2002-2025 David Frech. (Read the LICENSE for details.)

loading S08 memory image

( HC08s are big-endian, like all Motorola/Freescale processors!)
-d big-endian

ld target/common/memory-von-neumann-16.mu4

| For the S08 we need more than the default flash and ram regions, so let's
| start by getting a pointer to the memory image. It doesn't matter if we
| use ram or flash; there is only *one* image.
ram 'image

| Our additional zero-page regions:
dup make-region xram
dup make-region zram

| Since the boot page is made up of several pieces, let's make each piece
| its own region. wipe, below, will set reasonable origins for these.

dup make-region commit     | Git commit of chat version
dup make-region boot       | the bulk of the boot/chat code
dup make-region trims      | trims and security bytes
dup make-region vectors    | up to 64 bytes of vectors
drop

: wipe
     flash  @flash  region!  [ "1_0000 1 Ki 2/ - #]
    commit     dup  region!  | beginning of last page of flash
      boot     4 +  region!  | skip commit
     trims   "ffac  region!
   vectors   "ffc0  region!
      zram    @ram  region!
      xram    "100  region!
       ram    "100  region!

        0 image+ @flash  00 fill  ( zero RAM region)
   @flash image+ #flash "ff fill  ( erase flash to ff) ;

( Erase image memory and default to ram region.)
wipe

| xram is a bit odd. Sometimes we need to set aside a few bytes of zram
| for flash-based code - like the USB chat and BDM code - and never
| allocate these bytes to code or variables that we need while doing
| interactive development.
|
| My solution is to break the zero-page ram into two spaces: zram and xram.
| zram is "application" ram, and is allocated bottom up, from the @ram
| origin. xram is the "system" ram and is allocated top down, from 0100.
|
| Routines that might be necessary, say for programming flash, are by
| default placed at the "ram" origin - 0100. In the case of the USB code,
| we take advantage of this fact, and allow the write memory USB request to
| specify a wIndex value. 0 means "just copy the byte into memory";
| non-zero means "run the flash code at 0100 using wIndex as the command
| byte". This way it is almost trivial to run flash programming and erase
| commands via USB.
|
| But having these things be at arbitrary addresses seemed brittle and
| error-prone. This way they are at least somewhat fixed, and the memory
| allocation code checks to see if zram runs into xram.
|
| The best way to use these is to always load the "system" code even if
| it's already in flash, just so your code "knows" how much xram is
| allocated.