Disabling the front panel LEDS in the firmware need help.

[John Galt]

I managed to get the Address leds disabled and it greatly speed up my altairduino

however i'm almost where i need to be but not enough.

What do i need to disable in the firmware source code to

disable all LEDS on the front panel, but leave the panel Switch functions alone.

????

david, chris???

[da...@hansels.net]

The front panel LEDs are controlled by functions and #defines in the host_due.h/host_due.cpp files:

• To disable the Address LEDs, comment-out the body of function host_set_addr_leds() in host_due.h
• To disable the Date LEDs, find the "#define host_set_data_leds" in host_due.h and replace the 
  "REG_PIOD_ODSR_= v" with {}
• To disable the status LEDs, change all the #define host_set_status_led* and #define host_clr_status_led*
  macros by replacing the "REG_PIOx_xODR = ..." with {} for each of them

That should do it. However, these changes will make it impossible to use the external I/O bus. Only emulated
hardware will work after that. The I/O bus uses the same signals as the LEDs so you can't have one without the other. 
You should make sure to set USE_IO_BUS to 0 in config.h so the emulator doesn't try to use it.

David

[John Galt]

Thank you,

this if for an experiment anyway i have a seperate arudino due i'm messing with.

[John Galt]

also would disabling the VDM-1 and Dazzler gain any speed?

[da...@hansels.net]

It might but I don't think it will make a significant difference.

[John Galt]

cool, thank you again for the instructions, can't wait to test it out this evening.

[John Galt]

Interesting;

The Address LEDs comment them out and works fine.

"

To disable the Date LEDs, find the "#define host_set_data_leds" in host_due.h and replace the  "REG_PIOD_ODSR_= v" with {}

"

That results in a compiler error. 

if I change REG_PIOD_ODSR_= 0 just to force all the LEDs out it kind of Bricks the ROMs in memory and the hard drive rom does not load correctly just hangs, altair basically does not work. i can get into the configuration menu. 

I would imagine the Data LED update has to be disabled somewhere else to keep things correct. 

I would like to disable since that would increase speed.

I changed it back to the original "REG_PIOD_ODSR_= v" just left it alone.

Replacing the  "REG_PIOx_xODR = ..." with {}    also resulted in a compiler error, however i could "//" comment out everything and that worked.

The Leds for WAIT I had to preserve "status_wait" true or false flag but commented out the REG_PIOC_CODR = stuff.

 

I keep playing around because I'm so close to what i need. BIG progress with disabling things.

Additionally i had to disable the VDM and dazzler, disable the I/O Bus. i really don't need them for the experiment. if i get a success i will try to enable the dazzler and see what happens.

Reduced the available disk drives to just what i need. 

I need to keep the printer and the extra Serial ports. Not sure if there is anything else I could disable and get away with it.

With some Mbasic benchmark code i found;

The claim was if you ran the code and it completed in 50 seconds that was ~2MHz

If you ran the code on in 15 seconds that was ~6MHZ

I ran the modified firmware and managed 24.41 seconds. Which is around ~4Mhz

However looks like i need 4.5MHZ maybe 5Mhz to do what i need. It is so close its frustrating.

I'm still playing around trying one at a time since i kept bricking the Altair from running properly.

[da...@hansels.net]

Try "while(0)" instead of "{}". Basically what you want is for the #define to generate a C statement

that does nothing (and will then be optimized away by the compiler).

I can't try this right now so I'm not 100% sure what works and what doesn't.

[Tom Wilson]

Do you specifically need Altair firmware for this application? RunCPM is a bit more efficient, and if you couple that with turning on the compiler optimization for speed, I think you should hit 5MHz no problem. 

Tom Wilson
wils...@gmail.com
+1(619)940-6311 

--
You received this message because you are subscribed to the Google Groups "Altair-Duino" group.
To unsubscribe from this group and stop receiving emails from it, send an email to altair-duino...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/altair-duino/bbcdfba9-4dab-4a1c-ad96-2c802f8acdd3n%40googlegroups.com.

[John Galt]

I managed to lose 2 seconds messing around and now the benchmark is timing to 26.5 seconds. of course i can see it in the test results as well that it got slower.. ARUGH. 

I made enough changes that i'm not sure what caused the loss of 2 seconds. seems like it should have gone faster since i turned off more things.

I will try the while(0) but i have to call it a night i've been messing with it for a few hours now... :-(

also where are the Optimization configuration files where you set -03 or whatever i want to check if i turned off optimization in the past because i crammed everything into the DUE memory at one point and i remember i had to turn down an optimization setting or it would not fit in memory??

Tom; I was hoping to do this with the existing setup if i go to the runcpm based on what i have seen i'm going to be too limited. 

I can run a Altair emulator on my PC and crank the speed to unlimited but its defeating what i was hoping to do with the Altair-duino Package, or run the Z80 pack unlimited.

taking this all in,, i don't think I'm going to get enough speed to do what i need. I'm so close, i have thought about overclocking the DUE again the issue is the serial port timing also Scales with the overlock, 9600 ends up at 12000 or something. it messes up the terminal keyboard. was hoping to disable enough things to get the speed without overclocking as it was a fail last time.

Thanks again guys I'll keep playing with it.

[John Galt]

I managed to get back to the benchmark program running at 24 secs again. 

I undid some of the things I removed and put a few things back as they were. i used the while(0) in place of the '{}'

I ran the benchmark on one of my filled to the max Altair-duinos with the Speed limiter turned off and the same benchmark was 34 Seconds.

so the modifications are shaving about 10 seconds off the benchmark.

I don't have a completely stock setup altair-duino but i don't think the information i found about the benchmark taking 50 seconds as a base is correct.

 

if i change this line

#define host_set_data_leds(v) REG_PIOD_ODSR = v 

then everything goes haywire. it does not like {} or while(0) there either compiler fails. if i set REG_PIOD_ODSR = 0 then everything goes wrong as well since it needs the proper 'v' value.

Is there another place in the source code that just updates the Data LEDs outside of host_due.h?

I see in the main.ino there are lots of host_set_data_leds references. 

for the host_due.h

this is how i have the led code:

// ------------------------------------------ status LEDs

/* reading global variables is faster than reading back the i/o register
   => INTE and WAIT are read often so we keep their state in a global variable */

#define host_set_status_led_INT()   while(0) //REG_PIOB_SODR = 1<<25
#define host_set_status_led_WO()    while(0) //REG_PIOC_CODR = 1<<28
#define host_set_status_led_STACK() while(0) //REG_PIOC_SODR = 1<<26
#define host_set_status_led_HLTA()  while(0) //REG_PIOC_SODR = 1<<25
#define host_set_status_led_M1()    while(0) //REG_PIOC_SODR = 1<<23
#define host_set_status_led_MEMR()  while(0) //REG_PIOC_SODR = 1<<21
#define host_set_status_led_INTE()  while(0)  //REG_PIOD_SODR = 1<<8;
#define host_set_status_led_PROT()  while(0)  //REG_PIOB_SODR = 1<<27
#define host_set_status_led_WAIT()   { REG_PIOC_SODR = 1<<29; status_wait = true; }
#define host_set_status_led_HLDA()  while(0) //REG_PIOB_SODR = 1<<26

#define host_clr_status_led_INT()   while(0) //REG_PIOB_CODR = 1<<25
#define host_clr_status_led_WO()    while(0)  //REG_PIOC_SODR = 1<<28
#define host_clr_status_led_STACK() while(0)  //REG_PIOC_CODR = 1<<26
#define host_clr_status_led_HLTA()  while(0)  //REG_PIOC_CODR = 1<<25
#define host_clr_status_led_M1()    while(0)  //REG_PIOC_CODR = 1<<23
#define host_clr_status_led_MEMR()  while(0)  //REG_PIOC_CODR = 1<<21
#define host_clr_status_led_INTE()  while(0)  //REG_PIOD_CODR = 1<<8;
#define host_clr_status_led_PROT()  while(0)  //REG_PIOB_CODR = 1<<27
#define host_clr_status_led_WAIT()   { REG_PIOC_CODR = 1<<29; status_wait = false; }
#define host_clr_status_led_HLDA()  while(0)  //REG_PIOB_CODR = 1<<26

#define host_read_status_led_WAIT()   status_wait
#define host_read_status_led_M1()     (REG_PIOC_PDSR & (1<<23))
#define host_read_status_led_HLTA()   (REG_PIOC_PDSR & (1<<25))
#define host_read_status_led_INTE()   status_inte


#if USE_IO_BUS>0
// switch WAIT and DATA LEDs to inputs and turn on INP LED
#define host_set_status_led_INP()  while(0) //{ REG_PIOD_ODR = 0xFF; REG_PIOC_ODR = 1<<29; REG_PIOC_SODR = 1<<22; }
#define host_clr_status_led_INP()  while(0) // { REG_PIOC_CODR = 1<<22; REG_PIOC_OER = 1<<29; REG_PIOD_OER = 0xFF; }
// switch WAIT LED to input and turn on OUT LED
#define host_set_status_led_OUT() while(0) // { REG_PIOC_ODR  = 1<<29; REG_PIOC_SODR = 1<<24; }
#define host_clr_status_led_OUT() while(0) // { REG_PIOC_CODR = 1<<24; REG_PIOC_OER  = 1<<29; }
// read input from pins connected to DATA and WAIT LEDs
#define host_read_data_bus        while(0)   // host_read_data_leds
#define host_read_status_WAIT()    while(0)  // (REG_PIOC_PDSR & (1<<29))
#else
#define host_set_status_led_INP() while(0)  //  REG_PIOC_SODR = 1<<22;
#define host_clr_status_led_INP() while(0) //   REG_PIOC_CODR = 1<<22;
#define host_set_status_led_OUT() while(0) //   REG_PIOC_SODR = 1<<24
#define host_clr_status_led_OUT() while(0) //   REG_PIOC_CODR = 1<<24
#endif

when i change host_set_status_led_WAIT() and take out  REG_PIOC_CODR = 1<<29 or  REG_PIOC_SODR = 1<<29 it seems to run slower which is interesting.

address Leds are all commented out.

changing the data bus Led code from:

#define host_set_data_leds(v) REG_PIOD_ODSR = v

byte host_read_data_leds();

seems to break everything.

should

void altair_set_outputs(uint16_t a, byte v)
{
  host_set_addr_leds(a);
  host_set_data_leds(v);
  if( mem_is_protected(a) )
    host_set_status_led_PROT();
  else
    host_clr_status_led_PROT();
 
  if( host_read_status_led_M1() ) print_dbg_info();
  print_panel_serial();
}

be changed where host_set_data_leds(v); is commented out.

This is where i am at the moment. 

I also have the 4 top left leds still on as it seems if i play around with MEMR, MI, STACK, WO is breaks things.

[John Galt]

I played around and I got the benchmark to drop to 23.75seconds It was about 24.61 before so i got almost 1 second off the benchmark.

I can now make a connection to the device I'm playing with, But is just 98%-99% there. I need to turn off the DATA LEDs and I think that will be just what i need to get me over the top.

I killed off 2 of the upper left LEDs without causing an issue MEMR and WO and HLDA are all that are left if I mess with them it breaks things unless i can disable them somewhere else.

Soooooo clooooossseeee.....

[John Galt]

I modified

void altair_set_outputs(uint16_t a, byte v)
{

 // host_set_addr_leds(a);
 // host_set_data_leds(v);

  if( mem_is_protected(a) )
    host_set_status_led_PROT();
  else
    host_clr_status_led_PROT();
 
  if( host_read_status_led_M1() ) print_dbg_info();
  print_panel_serial();
}

and got the benchmark to 22.51 its almost 100% stable now.... the data leds are still lighting up from somewhere. i guess i can try killing off the PROT part of the code as well and see if that gains anything more.

still need to see if i can 100% disable the DATA leds.

I can work with this but i just need a hint more for 100% stablity.

[Tom Wilson]

Since you’re doing a one/off thing here, you could just do a mass search and replace and comment out all instances of host_set_data_leds(v). 

Tom Wilson
wils...@gmail.com
+1(619)940-6311 

To view this discussion visit https://groups.google.com/d/msgid/altair-duino/e67336a2-5410-476c-9993-2b4bdef6e36dn%40googlegroups.com.

[John Galt]

tried it runs slower, i lost back to 24.81 seconds on the bench and i have to use autoload for the roms its not responsive on powerup.

[John Galt]

undid everything and got back to 22.5 again.

as it is, i'm right at edge with what i need to do. I get an occasional drop out but it recovers, i couldn't do much of anything before so this worked. If there is anything else that would add more speed i would love it,i'm going to start working with what i have.

I tried to enable the dazzler support and lost 1 second back to 23.21 and sure enough with the dazzler enabled and the emulator running just that much slower what i needed to test failed completely.

22.5 is right on the ragged edge of what i need, if i got down to 22 that would be great if it got to 21.5 then i could enable the dazzler and get right on edge again.

 its really hairy LOL

[da...@hansels.net]

Ah, I forgot that in some instances the code uses the return value from host_set_data_leds().

try: #define host_set_data_leds(v) (v)

I remember that when I was optimizing the code for performance in some cases I found some really

un-intuitive changes, like I would remove lines of code and that made the whole thing run slower instead

of faster. I think that the way the compiler optimizes the code may be responsible for that. 

But really, if you need a faster emulation, there are other emulators out there for that.

The point of the AltairDuino was to emulate the front-panel LEDs as precisely as possible
(so things like kill-the-bit and the FM radio music demo would work). It was never meant to run
faster than 2 MHz emulated speed.

[John Galt]

understood.

 This was something i have been trying to do for a couple of years now and i got the bug to try it another way.

this time it worked. yup, I lost functionality but i have 2 other AltairDuinos that i have completely maxed out can't fit another byte in the DUE memory :) and everything works with them.

I'll try #define host_set_data_leds(v) (v) and see what happens :D.

i would love to see the dazzler running with this faster setup.... i still could i would just have to throw away what i'm doing and then i could just turn that back on and run my 3d render engine with it.

[John Galt]

AHHAHAHA

#define host_set_data_leds(v) (v)

got me to 19:85 seconds on the bench.

[John Galt]

hell yeah 

dazzler enable got me to 20:41 on the bench just a hair faster then before and what i need is working perfect

cool now i can try out my dazzler programs and see what happens.

[John Galt]

awesome all my dazzler stuff works way faster.

my dazzler piano sounds great. all the little programs i made work, my tron light cycle game runs super fast in the highest level.

The connection to the machine is solid now, wow what progress...

i also have a text to speech that will work over serial instead of I/O BUS.

the only loss is the RTC which i made some nice software for.

got my 3dcube rotating on the dazzler looking all happy.

if there is a real bench mark program to figure out just how fast its running somebody drop a note.

it has to be at least 4mhz.

[John Galt]

I realized i didn't post tom's benchmark program

10 PRINT CHR$(12)
30 FOR T=2 TO 200
40 TM=T/2:F=0
50 FOR I=2 TO TM
60 IF T/I=INT(T/I) THEN F=1:I=TM
70 NEXT I
80 IF F=0 THEN PRINT T;",";
90 NEXT T
100 END

somebody run that on their unmodified altair-duino with the CPU throttle enabled and tell me how many seconds it takes in MBASIC from RUN until OK.

on my modified machine that still runs around ~2Mhz i get 34 seconds.

on the machine I have modified i now get 20.41 seconds..

Tom reported that "RunCPM runs this in 15 seconds 6.67MHz effective"

Depending on how i run the scaling its either 3.2 Mhz or 5.2 Mhz, If I take the average i get ~4.2Mhz

My numbers are not right for the Baseline as there was a measurement of 50 Seconds posted some years ago.

if everyone is getting around 34 seconds then i'm ending up around 3 MHZ if everyone is ended up around 50 seconds then I'm around 5 Mhz.

i can see speeding things up a little with the I/O BUS still enabled if you don't mind losing some of the front panel LEDs

i still have 4-5 LEDs flashing with activity.