[Oberon] [EXT] Re: Project Oberon on Arty A7

Wed Dec 9 05:25:10 CET 2020

Chris:

Arty has the Arduino/ChipKit expansion pins. I do not know how "Arduino compatible" they are. I do not think there are enough pins on these connectors to add regular RAM chip like the Starter Kit used to have.  But perhaps they can be used to add memory using SPI RAM.

https://www.tindie.com/products/FemtoCow/spi-ram-shield-for-arduino/
https://learn.tinycircuits.com/Memory/SRAM_TinyShield_Tutorial/

Yes, I know... It is slow. And it talks via SPI calls. So it is weird. 

Wojtek

________________________________________
From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Chris Burrows [chris at cfbsoftware.com]
Sent: Tuesday, December 8, 2020 9:52 PM
To: ETH Oberon and related systems
Subject: [EXT] Re: [Oberon] Project Oberon on Arty A7

Jorg,

Yes - the stack size is unchanged. One of the self-imposed constraints for this particular exercise was to not modify the official Oberon sources. I wanted to put the focus on hardware instead of software. e.g. I've been designing an adapter PCB to free up two of the PMOD sockets. My initial off-the-shelf solution uses four of them. Monochrome VGA, 2 x PS/2 and the SD card together require less than sixteen pins so two PMOD sockets should be sufficient.

However, even if I had allowed myself to modify the sources, I can think of less risky ways of improving memory availability. e.g. using the remaining 28kB of BRAM on the Artix7-100T which I'm not currently using, coalescing adjacent empty module slots after unloading modules etc.

Unfortunately, however, it wouldn't have just stopped there. I would have found it difficult to resist implementing and using numeric CASE, eliminating undocumented features and many other 'improvements'.

Whenever you start on a journey like this you have to have a very clear idea of what your destination is and how long you have to get there if you are to have any hope of ever reaching it ;-)

Regards,
Chris

Chris Burrows
CFB Software
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.astrobe.com&d=DwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=HDhxAUcQ5twW7vP8kJ4JOjtL2hCng_1itUg2siEDx7s&s=bnk2RmFzrlwE-x25QdwctfIeumVSZNKi6dUxI8SqRds&e=

> -----Original Message-----
> From: Jörg [mailto:joerg.straube at iaeth.ch]
> Sent: Tuesday, 8 December 2020 8:48 PM
> To: chris at cfbsoftware.com; ETH Oberon and related systems
> Subject: Re: [Oberon] Project Oberon on Arty A7 (was: RISC-V Edition)
>
> Chris
>
> Great.
> So, I assume you used the  standard  32kB stack size reserved in the
> Oberon inner core (Kernel and Modules). In other words: Modules =
> 232+32 If in need, you could perhaps even reduce this a little bit to
> optimize RAM usage further.
>
> br
> J rg
>
> > Am 08.12.2020 um 07:24 schrieb Chris Burrows
> <chris at cfbsoftware.com>:
> >
> > ?
> >>
> >> -----Original Message-----
> >> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf
> Of
> >> Andreas Pirklbauer
> >> Sent: Tuesday, 8 December 2020 3:01 PM
> >> To: Oberon List
> >> Subject: [Oberon] Project Oberon, RISC-V Edition
> >>
> >> Hi Chris,
> >>
> >>>
> > FYI you can also use the Arty A7-100 board to run the official
> Project
> > Oberon Workstation using entirely off-the-shelf parts i.e.
> Digilent's
> > VGA, SDCard and PS/2 PMOD boards and cables. I succeeded in
> > implementing this recently using only the BRAM that is on the
> Artix-7
> > 100T board running at a clock speed 50% higher than normal (i.e.
> 37.5
> > MHz). As this means that the total RAM available is only 512 KB
> > (instead of the usual 1 MB) this does present some challenges.
> > However, it is possible to use the system to compile itself, using
> all
> > of the standard Project Oberon modules from Prof Wirth's site, even
> with the limited memory that is available.
> >>>
> >> Oh wow!!! And you don t run into heap space issues e.g. when
> >> compiling larger modules?
> >>
> >
> > I did initially. It took a while to find the optimum compromise
> between Module (+ global data +stack) size and heap size in Bootload.
> >
> > On the first attempt, only three modules of the compiler would
> load. Once that was fixed, the compiler ran out of heap space when
> compiling ORP or Draw. I finally settled on stackOrg = 042000H; That
> results in approximately the following breakdown of sizes given 512
> KB of RAM:
> >
> > Display   96 KB
> > Modules+ 264 KB
> > Heap     152 KB
> >
> > When the entire Project Oberon system is first loaded (a total of
> 13 modules), and before any compilation attempts, only 42% of the
> module space and 10% of heap space is actually used.
> >
> > It indicates to me that the 1 MB of RAM (assuming monochrome
> display) found on a standard Oberon Workstation should be more than
> enough for the average user. Of course, if you want colour, that is a
> different story.
> >
> > To confirm that the Arty A7 system works with the stock-standard
> Project Oberon system, I ran it with the disk image (RISC.img) from
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.projectoberon.com&d=DwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=HDhxAUcQ5twW7vP8kJ4JOjtL2hCng_1itUg2siEDx7s&s=jEKcpFjfuUpST2duRg2V5ZKzhgv1IpKG5GocPXQeLHQ&e=  rather than one I had built myself.
> >
> > Apart from Bootload, the only files that had to be modified for the
> > Arty A7 implementation were the Verilog sources and there wasn't
> > really that much that needed to be done. I would encourage others
> to
> > dive in and experiment - for me it is the best way to learn and it
> is
> > very rewarding. Because the RISC5 code is well-documented and
> > relatively straightforward (compared to some Verilog monstrosities
> > that I've seen) it is well within the capabilities of a Verilog
> > beginner e.g. me :)
> >
> > New module:
> >  RAM.v (91 lines - to use BRAM instead of SRAM. This was based on
> the
> > original written by Magnus Karlsson of Saanlima Electronics)
> >
> > Changed Modules:
> >  RISC5Top.v (~35 lines changed: faster clock speed, RGB leds, BRAM
> > instead of SRAM, generate pixel clock using PLL, fewer switches)
> > VID.v (~5 lines changed: external pixel clock generation)  RS232R.v
> (1
> > line changed: faster clock speed)  RS232T.v (1 line changed: faster
> > clock speed)  SPI.v (1 line changed: faster clock speed)
> >
> > I haven't included the constraints file ArtyA7-100.xdc. The work
> > consisted mainly of uncommenting the master file supplied by Xilinx
> to
> > enable the Arty A7 features actually used,
> >
> > Regards,
> > Chris
> >
> > Chris Burrows
> > CFB Software
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.astrobe.com&d=DwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=HDhxAUcQ5twW7vP8kJ4JOjtL2hCng_1itUg2siEDx7s&s=bnk2RmFzrlwE-x25QdwctfIeumVSZNKi6dUxI8SqRds&e=
> >
> >
> >
> > --
> > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> > systems https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=DwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=HDhxAUcQ5twW7vP8kJ4JOjtL2hCng_1itUg2siEDx7s&s=2_ZkzlocuaWM41gOy7Yrq9LXBsHBGc3TYcrVBnh8cMA&e=

--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=DwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=HDhxAUcQ5twW7vP8kJ4JOjtL2hCng_1itUg2siEDx7s&s=2_ZkzlocuaWM41gOy7Yrq9LXBsHBGc3TYcrVBnh8cMA&e=