Flashy Clock - Yet another DEV board

[PhilC]

LOL, ok. Well I'm pretty happy to get the chance to work with the one i've got.

[exxos]

Still working on this all day every day..

Currently working on the program bank menu. Erase and verify are now working, I faked a fail to make sure it worked.

The top 206 bank is highlighted black, as that is the currently running bank and you cannot program that one because it is in use etc..

Next up is to program the actual TOS flashing and verify...

IMG_5039.JPG (49.67 KiB) Viewed 5389 times

[rubber_jonnie]

Looking forward to getting my hands on one of these, and the HDMI adapter. So much so I will probably put off my 2nd H4 build!

[exxos]

Looking forward to getting my hands on one of these, and the HDMI adapter. So much so I will probably put off my 2nd H4 build!

H4 is the way of the future with all its compact addons

[exxos]

The mind boggles...

There is a count on the first row, 0-1498.. If the number is higher, it goes to zero.. yep works..

The second number, is INCR C% (ADD 1) ...

Actual code line...

Code: Select all

print #1,CL%,C%,BC%,L& ' debug to file 

INCR CL% : IF CL%>BC% THEN CL%=0 : CALL DRAWLINENEW (C%,3,WRITEBAR%,PROGRAMBACK%) : INCR C% 

So we can see CL% goes to zero.. yep.. draw a line.. yep.. add 1.. nope, jumps to 259 ?!

Code: Select all

 1493          0             1498          262144 
 1494          0             1498          262144 
 1495          0             1498          262144 
 1496          0             1498          262144 
 1497          0             1498          262144 
 1498          0             1498          262144 
 0             259           1498          262144 
 1             259           1498          262144 
 2             259           1498          262144 
 3             259           1498          262144 
 4             259           1498          262144 
 

[exxos]

Okay so I figured it out...kind of anyway...

The "fault" was in the subroutine itself...

Capture.JPG (42.77 KiB) Viewed 5358 times

Even highlighting 'X' it may not be so apparent.... Basically because OBJC_OFFSET returns X,Y and is not set by 'X' in the sub's declared variable 'X'.

The thing is though,At worst all this should have done is made 'X' simply the wrong number when it draws the bar, which it actually was doing.. Only I think because it was changing the count variable from the calling routine, I believe the compiler must have screwed up somewhere causing the value to be changed when it should not have been.. Of course the compiler would not have known that this would have been a error...

So the actual routine should have actually been..

2.JPG (45.95 KiB) Viewed 5358 times

[exxos]

Sneak preview on how easy it is to load use and programme a flash bank

[exxos]

Because TOS104 is 192K and not 256K like TOS206 etc, it slightly breaks my programming routine because of the different file length.. Technically does not matter do not program the remaining bytes, and indeed that is what the previous software did, and adjusted the progress bar accordingly.

However since writing the new software and splitting routines up into more sensible and manageable chunks, I ended up with a situation where I could not return the file length along with the location of the data in memory I could pass the file length as a global variable, But it just seemed a bit hacky

So my first idea was to use the "BLOAD" function, to load data into ram from a fixed variable size of 256K.. But my God, that function is slow! it literally takes several times longer to load in the file so I gave up with that approach.

My next idea was to do a loop along the lines of..

Code: Select all

WHILE L& < 262144
F$=F$+"FF":INCR L&
WEND 

But it seriously sucked, it was literally still going five minutes later!

My next idea was to do this instead...

Code: Select all

IF L& < 262144 THEN F$=F$+SPACE$(262144-L&)

And that worked and was considerably fast. The problem being that RAM usage ended up doubling for some reason I can only assume however the routine works at it makes a copy of the whole string data and I had to literally allocate 650K RAM for it to work. Normally the program is happy with 350K... 256K is needed for loading the ROM image.. likely the RAM usage could be reduced at a later date anyway.. But my main concern here was that the software would no longer work on a 512K machine

So I went back to the original loading routine which was the fastest and just tried this for the hell of it...

Code: Select all

OPEN fspath$+fi$ FOR INPUT AS #1
L&=LOF(1)
F$=INPUT$(L&,#1) + SPACE$(262144-L&)
CLOSE #1

Oddly now the RAM consumption I can set back to 350K. I guess some coders out there may know more technical reasons for this. I thought I would post about this "problem" as I thought it was a bit of a strange issue to have and not something I really considered about how strings work.

[troed]

Very language dependent ... but my guess would be that when evaluating "STRING$ = STRING$ +" it does make a copy of STRING$ first to be able to do the concatenation independent of the original.

[exxos]

So @Icky and I haven't had much time for this project lately A lot of problems are down to the fact the company we used to assemble stuff has been closed for some months and is likely to remain closed for a while yet. The lockdown we have both been maxed out with all sorts of work anyway

There are other companies I have tried to assemble stuff, but they want £30-£40 to assemble low volume boards. I'm not really comfortable just slapping on that on the final price as with all the chips on it already, it is already getting rather expensive.

Currently I am purchasing some more SMT gear so I can build up the (hopefully) final boards for testing. I'm currently tweaking the cream layer on the PCB to get a stencil made, which I think will help with a lot of soldering issues.

Once these boards are finalised, I just need to fix some graphical issues on the software mostly. The software can be fixed at a later date if needs be anyway. It is perfectly usable how it is now currently anyway.

Also, I said before, we are going to develop a H5 version which will not need the 3.3V IO buffers. So H5 versions will be cheaper to produce. Once those buffers are removed, I have plans to add another small chip on to do something else really cool