I have spent the weekend, on and off, sorting out some memory test functions for a small computer I am developing. These test functions are written in pidgin-C (my own special dialect) and although they didn't exist 2 weeks ago - over the last few days they have grown to almost a third of the 1200 lines of code, and represent adding considerable extra complexity - to something that started out as a neat idea contained in just 100 lines of code.
The memory device in question, is a 128K bytes RAM connected to the mcu via a SPI bus. Compared to what I usually work with, 128K bytes seems like a vast empty canvas, and I am like an Artist, or perchance a Cartographer - starting out to map out the territory that lies ahead of me.
Where to Start? How do you begin to draw lines in the desert? How best to partition the vast array of RAM into meaningful blocks and subdivisions? This time I think I will choose the "American" model - a series of logical blocks - laid out in a grid - after all - that is the internal structure of memory - however else we wish to abstract it.
The RAM is a Microchip 23LC1024, a 1Mbit part - and the larger version of the popular 23K256. According to the datasheet, this part has a 128K x 8 organisation with 32 bytes to a page, thus 4096 pages in the device.
32 bytes is a convenient sized unit of storage - especially when it comes to an interpreted language like Forth - consisting of short functions or words. 32 bytes is a good fit for a hex-dump routine and well suited to the modern Laptop screen resolution - where 128 characters + across the screen is not uncommon.
It allows for a function name, a code field address, a length, a payload of around 16 tokenised Forth characters and a character to either terminate the array, or to act as a continuation to the next page.
So each 32 byte page is a "pidgeon hole" into which you can post some source code, and by sticking to 32byte boundaries - it simplifies the addressing of the RAM and the storage, retrieval and movement of code. The 23LC1024 has a page mode for reading and writing RAM, which allows the address to be set up and the data - up to 32 bytes to be clocked out. This is much quicker than random byte addressing - which has the overhead of setting up a 24 bit address at the start of each RAM transfer.
In addition to "page mode" there is streaming mode - which allows for much larger transfers. In this mode you just have to specify the starting address, then just keep clocking bytes until you have transferred all you need. It works out at an average of about 3uS per byte, allowing the whole device to be dumped in about 0.4 seconds.
When Charles Moore got access to his first disk drive, he picked 1Kbytes as a convenient size for a block of code. Whilst the 1K block may have fallen from fashion in the modern Forths, within this educational environment, there are certainly valid reasons to re-instate the 1K block concept:
1. 1K of code fits nicely in the hex-dump window of the terminal application as 32 lines of 32 hex digit pairs - with accompanying ASCII to the right.
2. On the proposed machine - there is only 4Kbytes of SRAM on chip - so a 1K buffer to allow blocks to be swapped in and out of on-chip RAM seems sensible.
3. Many small Forth applications will fit into a 1K block of source code - particularly using tokenised code.
4. 1K of code can be transferred in about 3mS. That's about the duration of the vertical blanking interval (VBI) in some low resolution video standards - PAL etc. This allows for block transfers of the screen character buffer to be done during the VBI.
The memory device in question, is a 128K bytes RAM connected to the mcu via a SPI bus. Compared to what I usually work with, 128K bytes seems like a vast empty canvas, and I am like an Artist, or perchance a Cartographer - starting out to map out the territory that lies ahead of me.
Where to Start? How do you begin to draw lines in the desert? How best to partition the vast array of RAM into meaningful blocks and subdivisions? This time I think I will choose the "American" model - a series of logical blocks - laid out in a grid - after all - that is the internal structure of memory - however else we wish to abstract it.
The RAM is a Microchip 23LC1024, a 1Mbit part - and the larger version of the popular 23K256. According to the datasheet, this part has a 128K x 8 organisation with 32 bytes to a page, thus 4096 pages in the device.
32 bytes is a convenient sized unit of storage - especially when it comes to an interpreted language like Forth - consisting of short functions or words. 32 bytes is a good fit for a hex-dump routine and well suited to the modern Laptop screen resolution - where 128 characters + across the screen is not uncommon.
It allows for a function name, a code field address, a length, a payload of around 16 tokenised Forth characters and a character to either terminate the array, or to act as a continuation to the next page.
So each 32 byte page is a "pidgeon hole" into which you can post some source code, and by sticking to 32byte boundaries - it simplifies the addressing of the RAM and the storage, retrieval and movement of code. The 23LC1024 has a page mode for reading and writing RAM, which allows the address to be set up and the data - up to 32 bytes to be clocked out. This is much quicker than random byte addressing - which has the overhead of setting up a 24 bit address at the start of each RAM transfer.
In addition to "page mode" there is streaming mode - which allows for much larger transfers. In this mode you just have to specify the starting address, then just keep clocking bytes until you have transferred all you need. It works out at an average of about 3uS per byte, allowing the whole device to be dumped in about 0.4 seconds.
When Charles Moore got access to his first disk drive, he picked 1Kbytes as a convenient size for a block of code. Whilst the 1K block may have fallen from fashion in the modern Forths, within this educational environment, there are certainly valid reasons to re-instate the 1K block concept:
1. 1K of code fits nicely in the hex-dump window of the terminal application as 32 lines of 32 hex digit pairs - with accompanying ASCII to the right.
2. On the proposed machine - there is only 4Kbytes of SRAM on chip - so a 1K buffer to allow blocks to be swapped in and out of on-chip RAM seems sensible.
3. Many small Forth applications will fit into a 1K block of source code - particularly using tokenised code.
4. 1K of code can be transferred in about 3mS. That's about the duration of the vertical blanking interval (VBI) in some low resolution video standards - PAL etc. This allows for block transfers of the screen character buffer to be done during the VBI.