MCODEing on OSX

[Ángel Martin]

(04-07-2019 07:26 AM)Jurgen Keller Wrote:  I understand this is a matter of personal taste and habits. I also heard that Angel is using spreadsheets.

Quite right on both accounts, a personal thing indeed - heavily influenced by the skills and previous knowledge of tools. I'm too old a dog to learn difficult new tricks so I use EXCEL sheets (a.k.a. the "blueprints"), but contrary to Sylvain's mine are *very* manual (read: error prone, tedious checking, etc) - not recommended for general usage. I have no problem sharing them if anybody's interested but be aware that there's no macros or clever formulas in them. I believe there are a few posted on TOS.

ÁM

[hth]

One of the amazing things about MCODE is when you start your project and "create" a new 4K page, that tiny canvas, there is so much functionality that can be squeezed into it. I have seldom met anything quite like it.

This community is just too small for anything to really happen. We are also quite diverse on how we work, the things that do get done. This is a matter of personal taste I suppose.

We have different instruction sets, different ways of entering code and are far apart from agreeing on anything that is even resembles something similar. With git and hosting, it is possible to create public projects, download, build and collaborate. However, we are just too few people spread out that do things differently, it is just impossible.

Apart from instruction sets and ways to enter code, we even have a limited system address space. I have a great idea (I believe, and I already started a bit on it) to make a generic system extensions module. The main problem is that it requires page 4 and Angel has already claimed it. It would need access to those cold start vectors to pull it off, but that is not possible now. Yes, I suppose I could do it anyway, but who would use it? If I make a couple of modules, what is that going to be against the 20 popular modules Angel makes. So even if I did make it, there will just be me using it in the end.

I think there is no point with a Slack channel, there is too little is happening. I can always use the forum as my rambling area instead, if I find some time at some point and feel like it.

Now I head back to my other projects.

[Monte Dalrymple]

(04-07-2019 06:41 PM)hth Wrote:  One of the amazing things about MCODE is when you start your project and "create" a new 4K page, that tiny canvas, there is so much functionality that can be squeezed into it. I have seldom met anything quite like it.

This community is just too small for anything to really happen. We are also quite diverse on how we work, the things that do get done. This is a matter of personal taste I suppose.

We have different instruction sets, different ways of entering code and are far apart from agreeing on anything that is even resembles something similar. With git and hosting, it is possible to create public projects, download, build and collaborate. However, we are just too few people spread out that do things differently, it is just impossible.

Apart from instruction sets and ways to enter code, we even have a limited system address space. I have a great idea (I believe, and I already started a bit on it) to make a generic system extensions module. The main problem is that it requires page 4 and Angel has already claimed it. It would need access to those cold start vectors to pull it off, but that is not possible now. Yes, I suppose I could do it anyway, but who would use it? If I make a couple of modules, what is that going to be against the 20 popular modules Angel makes. So even if I did make it, there will just be me using it in the end.

I think there is no point with a Slack channel, there is too little is happening. I can always use the forum as my rambling area instead, if I find some time at some point and feel like it.

Now I head back to my other projects.

If you are writing something for the CL, the MMU makes it possible to dynamically load stuff into Page 4. You don't have to move anything because only the MMU entry for Page 4 changes. This is the technique I use with the 41CL Extreme Functions (YFNX), which makes extensive use of the 4LIB image. I do the same thing when I am dealing with Flash, although in this case I do have to move sections of code into RAM before reprogramming the MMU. I then jump into Page 4 (executing out of RAM) while I do the Flash erase/write stuff.

If your Page 4 System Extensions are called by functions I would recommend using this approach. The sources for YFNX and YLIB are on the 41CL website. The one complication doing this is error handling. You can't just display an error and exit, because you always have to undo the MMU remapping. Again, YFNX and YLIB show how I do this.

I use dedicated code in the module to do the dynamic paging, but if your CL is up-to-date the same code is available as a subroutine in Page 3.

I agree that doing MCODE is extremely rewarding and it is amazing what can be done in 4K. I also love going through the HP listings looking for tricks and the inevitable "why didn't I think of that" moments.

Monte

[hth]

Unfortunately it is not for the 41CL. The reason is that I have 3 Halfnut CX machines and one old CV converted to a 41CL. It does not make sense to me to do that development and only have it working on one of the machines, also being the oldest and most worn one. I need something that can work on all of them.

If I did it for the 41CL I would probably just reprogram the internal ROMs instead, it would make it even easier.

[Ángel Martin]

(04-07-2019 08:53 PM)hth Wrote:  If I did it for the 41CL I would probably just reprogram the internal ROMs instead, it would make it even easier.

This reminds me the ultimate challenge: re-program the OS to take advantage of the CL memory space... a daunting and probably useless project considering the immense amount of work required, the likelihood of messing up a wonderful design, and the little to no use to anybody except the three usual suspects.... although these very same three considerations may also be the definition of a dream challenge ;-)

Well, maybe not the complete OS but I'd start with the extended memory management - all those voids in-between modules are a real shack and hassle and sure could go away if we put the work to it. Is this feasible?

ÁM

[derekamos]

ÁM wrote:
Well, maybe not the complete OS but I'd start with the extended memory management - all those voids in-between modules are a real shack and hassle and sure could go away if we put the work to it. Is this feasible?
---
I would say never mind EX memory management, could those spaces become patches for the main 3x ROMs. With minimum alteration to pages 1,2,3 except for calling/running the extra programmed routines?
(just an idea!) DA

[Monte Dalrymple]

(04-08-2019 08:04 AM)Ángel Martin Wrote:  

(04-07-2019 08:53 PM)hth Wrote:  If I did it for the 41CL I would probably just reprogram the internal ROMs instead, it would make it even easier.

This reminds me the ultimate challenge: re-program the OS to take advantage of the CL memory space... a daunting and probably useless project considering the immense amount of work required, the likelihood of messing up a wonderful design, and the little to no use to anybody except the three usual suspects.... although these very same three considerations may also be the definition of a dream challenge ;-)

Well, maybe not the complete OS but I'd start with the extended memory management - all those voids in-between modules are a real shack and hassle and sure could go away if we put the work to it. Is this feasible?

ÁM

For compatibility, those holes are enforced by the 41CL hardware. So even though the RAM is present in all those locations, the CPU fetches data from the bus rather than the RAM in those holes. Changing that would require reprogramming the FPGA.

Monte

[Ángel Martin]

(04-08-2019 02:25 PM)Monte Dalrymple Wrote:  

(04-08-2019 08:04 AM)Ángel Martin Wrote:  Well, maybe not the complete OS but I'd start with the extended memory management - all those voids in-between modules are a real shack and hassle and sure could go away if we put the work to it. Is this feasible?

ÁM

For compatibility, those holes are enforced by the 41CL hardware. So even though the RAM is present in all those locations, the CPU fetches data from the bus rather than the RAM in those holes. Changing that would require reprogramming the FPGA.

Monte

So I guess this puts the last nail in this coffin... moving on to other ideas!
Does this mean the holes are "available" for other purposes then?

ÁM